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ABSTRACT 


The Least Privilege Separation Kernel (LPSK) is part of the Trusted Computing 
Exemplar (TCX) project. Separation kernels may be used to partition resources in support 
of the enforcement of mandatory security policies. The LPSK provides services that 
allow each subject to access resources configured as part of its domain. To ensure 


permanence of information the LPSK requires a storage hierarchy for its data resources. 


This thesis describes the design for a LPSK storage hierarchy based on existing 
LPSK requirements. The design was implemented in a Linux environment to produce a 
storage hierarchy prototype. Implementation of the prototype proceeded in keeping with 
principles for developmental security which include minimization, modularity, and 
hierarchical dependencies. The LPSK storage hierarchy external interfaces belong in 
three distinct categories: The configuration interfaces are used to construct the storage 
hierarchy and its contents in a non-LPSK context, initialization interfaces associate data 
segment handles with data segments that are exported to LPSK subjects, and runtime 
interfaces support the reading and writing to secondary storage data segments exported to 
non-LPSK subjects. Testing showed that storage hierarchy interfaces behaved according 
to specification. This study shows that a storage hierarchy prototype can be designed and 


implemented based on the LPSK functional specification. 
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I. INTRODUCTION 


A. MOTIVATION 


The size and complexity of modern computing systems, and governmental and 
private organization’s reliance on these systems to process sensitive information, has 
increased the attention paid to the threat of system exploitation and unintended 
information flow. Users rely on system security mechanisms to enforce policies regarding 
the flow of information between various system components. A system’s security policy 
however is not always equivalent to the actual security policy enforced by the system. 
The certainty of a system’s ability to enforce a security policy can only be measured by 
the analysis of policy-enforcing mechanisms. A high level of certainty, or assurance, that 
a system will behave as configured increases confidence in that system’s ability to 


correctly process sensitive information. 


The goal of the Trusted Computing Exemplar (TCX) project is to develop an 
example of a high assurance computing platform. The core operating system, or kernel, 
of the TCX computing platform will provide a high level of assurance that only explicitly 
defined information flow can occur between entities hosted on the platform. The Least 
Privilege Separation Kernel (LPSK) contains the mechanisms for separating system 
subjects and resources into partitions, as if they were located in distributed systems, and 
controlling the flow of information between these partitions. This information flow policy 


is part of the configuration of an LPSK system. 


Operating systems need file systems to store data over long periods of time. So 
does the LPSK. The LPSK provides long-term persistence of information for its hosted 
subjects through the LPSK storage hierarchy. The motivation of this thesis is to develop a 
storage hierarchy prototype that meets the requirements of the TCX project and the 
functional requirements of the LPSK. The storage hierarchy prototype is an LPSK 


module that facilitates the secondary storage of data segments in a tree-like structure. 


While similar to conventional file systems in many ways, the storage hierarchy differs 
from these systems in that it is designed to intentionally avoid the potential of 


information flow through a resource exhaustion covert channel. 


B. PURPOSE OF STUDY 


The objective of this research was to analyze the LPSK storage hierarchy 
requirements, map these requirements to a storage hierarchy design, and then implement 
this design as a prototype LPSK module. An interface specification document was 
authored to define the boundary between the storage hierarchy module and the LPSK and 
LPSK configuration tools. The module was tested to ensure it behaved according to the 
interface specification. This study contributes original work to the TCX project and 
furthers its goals of developing an openly available example of a high assurance 


computing platform. 


C. THESIS ORGANIZATION 


This thesis is organized as a series of chapters. Chapter I describes the motivation 
and purpose of this thesis. Chapter II provides background information on the TCX 
project, separation kernels and the LPSK, file system organization, and the LPSK storage 
hierarchy. Chapter III contains the storage hierarchy requirements, interface and data 
structure designs, and implementation details. This chapter makes the distinction between 
three types of storage hierarchy external interfaces. Chapter IV documents storage 
hierarchy external interface test results. Functional testing was performed on all 
interfaces in conjunction with negative testing for error cases. Chapter V concludes this 
work with a discussion of the study’s results, lessons learned, and suggestions for future 


work. 


I. BACKGROUND 


This chapter serves to provide the reader with basic understanding of the Least 
Privilege Separation Kernel of the Trusted Computing Exemplar project and the LPSK 
Storage Hierarchy specifically. The concepts of trusted computing and separation kernels 
are introduced in the first section. The second section introduces the Storage Hierarchy as 
an analog of file systems and discusses file system concepts as they relate to the LPSK 


storage hierarchy. 


A. TRUSTED COMPUTING EXEMPLAR PROJECT 


Public demand for computer software technology, and the rapid development of 
technology to satisfy this demand, has resulted in insufficient consideration given to the 
trustworthiness of systems intended to protect both code and data. There are no recent 
openly available examples of highly trustworthy software products that show how such 
systems are built [1]. The purpose of the TCX project is to address this lack of trusted 
computing technology by developing open and documented examples of software 
systems that can be verified and proven to provide high assurance. High assurance is 
achieved by showing that systems operate correctly and according to specification. 
Output of the TCX project will satisfy the demand for knowledge in the area of trusted 


computing. The four main activities of the TCX project follow are: 


e Creation of a prototype framework for rapid high assurance system 


development; 
e Development of a reference-implementation trusted computing component; 
e Evaluation of the component for high assurance; and 
e Open dissemination of deliverables related to the first three activities [1]. 


The following three sections discuss trusted computing, separation kernels, and the TCX 


Least Privilege Separation Kernel. 


1. Trusted Computing 


Trusted Computing is an approach to computer architecture and software 
development and evaluation that considers both the risks of system penetration by frontal 
attack and system subversion. The methods employed to show that both categories of risk 
are properly addressed will also show that the system in question operates correctly and 


can thus be trusted. 


Frontal attacks are those that exploit behaviors in a system that were inadvertently 
included by its developers. Frontal attacks rely on the exploitation of either documented 
or undocumented flaws in a system. Subversion is the purposeful placement of an 
artifice, or trap door, into a system during design or implementation that circumvents 
normal system controls when instructed to do so by specific stimulus [2]. Subversion can 
occur at any time during a system’s life cycle and can be designed to completely bypass 
all system controls meant to protect the system’s integrity. Ensuring that either case of 
attack is not possible requires a system to be implemented with no exploitable flaws and 


without subversive artifices. 


Modern computer systems are often comprised of hundreds of thousands, or even 
tens of millions, of lines of code. It is infeasible to analyze such large and complex 
systems by source code inspection or security test and evaluation to determine a lack of 
exploitable flaws and malicious artifices [3][4]. Furthermore, subversion of a system can 
occur in its earliest development phases, confounding future attempts at detection. 
Trusted Computing methodologies are intended to prevent subversion by requiring exact 
and unambiguous specification of all system databases and functions from the very first 
design phases of the system. When combined with rigorous configuration management, 


this increases confidence in the integrity of the system from inception through retirement. 


Formal methods are used to show that the security policy of the system enforced 
by its security mechanisms is mathematically correct. A system’s security policy 
represents all permissible interactions between subjects or processes and data. Since these 
permissible interactions are potential targets of subversion, the security mechanisms that 


enforce the security policy of the system must be verifiable against some standard 
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criterion to show they work correctly. The Common Criteria (CC) supports the creation 
of a common set of requirements and evaluation techniques to express some measure of 


confidence in this verification of security mechanisms [5]. 


The CC was developed by several cooperating countries to provide a recognized 
standard for providing security guidance to vendors, and a framework to evaluate system 
controls and security mechanisms [5]. A protection profile is developed to require a 
particular level of assurance, with higher evaluation assurance levels (EALs) requiring 
more stringent and exacting requirements. For instance, successful EAL1 validation 
provides confidence a system will operate correctly where security threats are of little 
concern, while EAL7 validation provides confidence that the security policies will be 
correctly enforced even in the face of major threats. A system that is evaluated at EAL7 
will have been developed with both frontal attacks and subversion risks fully considered 


and guarded against. 


Trusted Computing attempts to prevent successful frontal attack and system 
subversions by addressing the origination of these risks in planning and implementation. 
By formally modeling and proving the correctness of a system’s design, and validating its 
implementation against a set of standards such as the CC, the trustworthiness of a system 


can be established. 


2 Separation Kernels 


The kernel is the core of an operating system and has direct and complete control 
over all of the systems resources, including the operating system, and user applications 
and data. The interaction of applications and users by way of data flow in the system is 
mediated by controls in the kernel. Without assurance provided for the correctness of 
these kernel controls, no assertions can be made about the interactions and data flows 


they are meant to control. 


Security kernels attempt to provide assurance by consolidating their basic controls 
and security mechanisms into a minimal, verifiably correct core, or kernel. The 
interactions and data flows of the system are then mediated from this trusted core, which 


becomes the enforcer of a system-wide security policy [6][7]. This approach is 
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complicated with the introduction of “trusted processes” to the system [8]. These 
processes are less constrained by the mechanisms of the security kernel in order to carry 
out necessary tasks that are otherwise forbidden by the system’s security policy: for 
example, re-grading the classification level of information in a multilevel system. The 
verification of a system that uses trusted processes must now extend outside the security 


kernel to those processes, contrary to the original intent of these kernels [8]. 


In 1981, Rushby suggested a new class of security kernels called separation 
kernels [8]. He observes that no data flow can occur in a physically separated system of 
individual computers by virtue of their disconnectedness. The data flow policy of the 
overall system is determined by how the individual computers are physically connected 
by communication channels. Individual computers in the distributed system may not 
influence the operation of other computers unless communication is authorized by the 
data flow policy. A separation kernel emulates the properties of this distributed system in 
one physical system by creating multiple, virtual execution environments, and enforcing 


a data flow policy between them [8]. 


Separation kernels separate the resources of a system (such as subjects and data) 
into partitions. Subjects in one partition may not interact with data in another partition 
unless this interaction has been explicitly allowed by the data flow policy enforced by the 
separation kernel. The data flow policy of the system is defined by the configuration of 


the partitions, their contents, and the communication channels between them. 


The Information Assurance Directorate of the United States Government 
published “The U.S. Government Protection Profile for Separation Kermels in 
Environments Requiring High Robustness.” This document defines the Separation Kernel 
Protection Profile (SKPP); the requirements for a high assurance separation kernel [9]. 
The TCX LPSK is being built to comply with the SKPP, and is targeted for evaluation at 
EAL7. 


Figure | illustrates a simple separation kernel configuration which contains three 
partitions, three subjects, and a number of resources distributed amongst them. Arrows 


represent interaction or the flow of information to or from subjects. An arrow pointing 
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towards a subject denotes that subject’s ability to read from the source of the arrow. An 
arrow pointing from a subject denotes the ability to write. A double-headed arrow shows 
read/write capability. The SKPP refers to a partitioned information flow policy (PFIP) to 
describe data flow between subjects and resources of the same or different partitions. 
This allows for more granular data flow control than Rushby’s general inter-partition 
communication concept [9]. In this example, Subject 2 located in Partition A is capable 
of writing to a resource in Partition B, which is also read/writable by Subject 3. Subject 3, 
however, has not been allowed to communicate with other resources in his partition. This 
flow of data that occurs between partitions, and between subjects and resources within 


partitions, is explicitly declared in the configuration data of the separation kernel. 
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Figure 1. Separation kernel configuration example from SKPP document [9]. 





The TCX implementation of a SKPP-compliant separation kernel, the LPSK, is 


discussed in the next section. 


3. TCX Least Privilege Separation Kernel 


The TCX LPSK is a separation kernel implementation that is compliant with the 
SKPP [10]. It enforces two data flow policies: partition-to-partition and subject-to- 
resource. The intersection of these two policies produces a correct SKPP PIFP. The 
subject-to-resource policy determines what resources a subject may read from or write to. 


Between partitions, the partition-to-partition policy determines what resources a subject 


located in another partition may interact with. As required by the SKPP, the LPSK is 
configured prior to system operation by way of a configuration vector that defines the 
partitioned subjects and resources, and PIFP of the system [9]. 

One type of resource made available to subjects in an LPSK system is a segment. 
Segments represent blocks of data that subjects may read from or write to during the 
course of their execution. A segment that is ephemeral and exists only in primary 
memory is referred to as an “mseg” while a segment that is stored long-term across 
multiple system power cycles is called a data segment, or “dseg.” The TCX LPSK 
Storage Hierarchy, which provides mechanisms for storing and retrieving data segments, 


is discussed in the next section. 


B. STORAGE HEIRARCHY 


The applications that run on the LPSK require several basic system services 
regarding the maintenance and persistence of their data. First, they must be able to use 
portions of system primary memory to perform their operations, and second they may 
save the contents of their primary storage to a secondary storage area for later retrieval. 
Applications may also require certain data be available at the beginning of their 
execution, e.g., when an LPSK system has just started. This data must be available from 


some secondary store that is present before system startup. 


These expectations are common on many modern operating systems, and have 
traditionally been served by a memory manager and file system. Memory managers allow 
applications to reserve portions of system memory while preventing unwanted 
modification of protected or otherwise unshared memory. File systems store application 
and system data on some medium, and maintain data structures necessary to track the 
locations of various data segments. The LPSK Storage Hierarchy subsystem is available 


to the LPSK memory manager for the storage and retrieval of data segments. 


The following sections discuss traditional file systems as secondary storage 
managers, the LPSK Storage Hierarchy as a specialized subsystem that supports the 
LPSK mission of data-domain separation, and the concept of data segments and how they 


are stored. 


if File Systems 


Long-term storage of application data in primary storage (main system memory) 
is not possible due to the volatility of memory. Random-access memory (RAM) 
maintains its state by applying electrical current to a series of transistors (SRAM) or 
transistors and capacitors (DRAM). When a system is turned off and the electrical current 
is no longer applied, any information stored in memory is rapidly lost. The cost of 
transistor-based storage is also a concern. While much faster in terms of operations per 
second, transistor-based storage is much more expensive than non-volatile storage. 
Secondary storage provides long-term, stable storage of data that persists across system 
power states. This has traditionally been accomplished in contemporary computer 
systems by use of magnetic hard disk drives, though there is a slow trend toward large- 
scale solid-state drives. Generally, a file system is responsible for maintaining data on a 


non-volatile storage medium in a way that makes files accessible to the rest of the system. 


The architecture of various storage media has often influenced the design of 
contemporary file systems. For instance, the smallest unit of data a file system presents to 
a client to interact with is derived from the way hard disk drives store binary data on their 
magnetic platters. Even though emerging solid-state drive technology does not share the 
mechanical limitations of traditional hard disk drives, the conventions developed around 


the use of hard disk drives are still generally applied to the new class of solid-state drives. 


Hard disk drives store binary data on rotating magnetic platters, or disks. The 
surface of the platters is partitioned into many disk sectors. A sector is read or written in a 
single atomic operation. Each sector traditionally stores 512 bytes of data, although hard 
disk drive vendors have agreed to increase sector sizes to a standard of four kilobytes in 
the near future [11]. The hard disk drive controller—the integrated circuits that facilitate 
communication between the hard disk drive and an overall computer system—presents 
the collection of physical sectors as a linear span of addressable blocks [12]. These 
logical blocks are mapped to physical sectors by the hard disk drive controller. File 


systems use this logical view of hard disk drives to store files. 


A file is a bounded sequence of data bytes that is meaningful to the system or 
applications that run on a system. A file system is a collection of files and the data 
necessary to determine the boundaries between files on the medium in which they are 
stored [13]. A file system’s locater information, or meta-data (data about the data stored 
in the file system), maintains the actual location of files by address on the medium, 
addresses available for allocation to files, and the logical structure of a file hierarchy. File 
systems can provide a logical model of a file hierarchy by identifying the location of files 


within a tree structure comprised of directories and sub-directories. 


File system directories are special interpretively accessed objects that contain 
information about their direct descendents in the logical hierarchy. This includes both 
location and metadata information. File systems that maintain only one directory are 
considered to be flat or single layer file systems, while hierarchical file systems are those 
that allow the creation of sub-directories as children of the primary directory [13]. In 
either case, applications that utilize a file system to store data need not be aware of the 
physical layout of data bytes across the storage medium, but can instead rely on a naming 


convention to identify and reference files. 


The size of files is measured in bytes. Files can be expected to grow or shrink in 
size as they are modified. They can also be removed entirely. Also new files may be 
created. In order to accommodate dynamic restructuring of its data, file systems partition 
their storage media into individual blocks of some byte length and maintain a list 
referencing every block the file system is responsible for [13]. This partitioning allows a 
file system to reduce the amount of memory required to address all of its space, while 
allowing files to be allocated across consecutive or nonconsecutive free blocks using 
group chaining. Even though a file might not be located on consecutive blocks of the 
medium due to fragmentation, the file system can follow the linked list produced by 


group chaining to find each block that comprises the file. 


Figure 2 demonstrates the allocation of a file named “myfile” across a series of 
blocks in a file system. Omega, Q, denotes the end of a group chain of blocks, while an 
empty block means that block has not been allocated to a file and is available for 


allocation. Any other value represents the address of the next block in the group chain the 
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file system should read from for the next part of a file. The directory mentioned 
previously resides at the first block and contains the single entry for “myfile”. The 
directory shows that the first block of the group chain that contains “myfile” is at address 
1 in the overall group of blocks. The entry at block 1 tells the file system that the next 
block of “myfile” is located after it at block 2. Following the linked list produced by the 
group chaining, the file system learns that the last block of the file is located at block 5. 
The fact that block 3 is empty suggests that it was previously allocated to a file that is no 
longer present in the file system. In the simplest file allocation scheme, if a new file is 
added to this example layout, it would be allocated block 3 for the first part of the file. If 
any successive blocks were necessary to store the file, they would be allocated at block 6 


and sequentially thereafter. 





Myfile 


Directory 





Figure 2. Example of file allocation across a logical file system block set 


File systems store system and application data on non-volatile (or volatile) media. 
They abstract the complexity of organizing files on a storage medium and provide a 
simple hierarchical structure of files to users and applications. The following section will 
show that the LPSK Storage Hierarchy is a specialized file system that provides similar 
functionality while adhering to design specifications of the LPSK and the TCX project. 


pa LPSK Storage Hierarchy as a File System 


The LPSK Storage Hierarchy (hereafter referred to as the storage hierarchy) 
provides secondary storage by arranging data into a hierarchical set of data segments. A 
data segment is an abstraction for data storage and is used as a container for a subject’s 
data in primary memory and secondary storage [14]. During the operation of the LPSK 
system, the file system retrieves data segments from the storage hierarchy to load into a 
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subject’s primary memory space, or flushes segments located in primary memory into the 
appropriate secondary storage segment. In this mode of operation, the storage hierarchy is 
analogous to a traditional file system, where data segments are similar to files and the 
overall storage hierarchy is analogous to a file system. However, there are some 


important distinctions. 


Since the resources and data to which a subject has access are statically declared 
as part of the system’s configuration, no new secondary storage data segments can be 
created during system operation. Likewise, data segments cannot be destroyed during 
operation. The dimensions of data segments in terms of their length in bytes are also 
declared as part of the configuration of the system. These three considerations imply a 


storage hierarchy whose structure and dimensions are static. 


The storage hierarchy organizes data segments in a tree structure beginning with a 
notional root node, ‘/’, that represents the root directory. Each node of the hierarchy may 
have one or more child nodes, up to a maximum number of children defined in the 
configuration of the system. Node entry numbers (the name of the node that differentiates 
it from its siblings) may be any number between zero and the maximum number of 
children minus one as mentioned before. Child nodes of the same parent may not share 
the same label. Concatenating a child node’s label with its parent’s label separated by 
forward slashes produces the absolute path to that node from the root node. In our 
interpretation of the storage hierarchy, a child node is either a data segment or a directory 
node. Data segment nodes are leaf nodes that correspond to secondary storage data 
segments while directory nodes correspond to internal nodes within the tree that may 


contain additional children nodes. 


Figure 3 shows a logical model of a storage hierarchy which contains six 
secondary storage data segments and four directory nodes. The arrows show the lineage 


of parent nodes. 
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Figure 3. Example of a notational storage hierarchy tree structure 


During configuration of an LPSK system, the exact structure of the storage hierarchy and 
dimensions of data segments are defined, and the contents of the secondary storage data 
segments are pre-loaded as necessary. The LPSK ensures that only subjects that are 
configured to access the corresponding data segment in primary memory, as defined by 
the LPSK system configuration, may access that secondary storage data segment in the 


storage hierarchy during run-time [14]. 


Accessibility to secondary storage data segments is provided by the three 
operations subjects may perform on data segments; swap in, swap out, and flush. A 
subject’s primary memory space is limited by the configuration of the system and 
indirectly by the physical resources provided by the hardware on which the system runs. 
Because of potential limited space, subjects may need to move their data segments out of 
primary memory and into secondary storage, followed by the reverse. Swapping a data 
segment into a subject’s primary memory space loads the contents of the corresponding 
secondary storage data segment. Swapping out a data segment overwrites the contents of 
the secondary storage data segment with the contents of the data segment in primary 
memory and frees that primary memory for the swapping in of other data segments 
associated with that process. Flushing a data segment overwrites the contents of a 
secondary storage data segment while keeping the corresponding data segment intact in 


primary memory. 


13 


After an LPSK platform is configured and the LPSK is started, the LPSK 
initialization routine reads the configuration data and imports the specified data segments 
into primary memory. The initialization routine manages this importation by passing 
requests to the storage hierarchy. The storage hierarchy constructs a data structure in 
main memory that associates a data segment handle with the absolute path of a secondary 
storage data segment. When the kernel or its subjects need to perform an action on an 
imported segment, the handle is passed to the storage hierarchy as an identifier of the 


segment to be acted upon. 


This section has demonstrated that the LPSK storage hierarchy is a specialized 
file system that facilitates the secondary storage of LPSK data segments. The concept of 
a data segment in primary memory or secondary storage has been introduced along with 
the tree-like structure of the storage hierarchy. The next chapter of this thesis describes 
the requirements, technical design, implementation methodology, and implementation of 


the storage hierarchy. 
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HiIl. DESIGN AND IMPLEMENTATION 


This chapter is separated into four sections: requirements, design, implementation 
methodology, and implementation. The requirements for the storage hierarchy prototype 
are described first, followed by a description of how the requirements are met by the 
design of the storage hierarchy prototype’s data structures and interfaces. The third 
section describes the development environment and tools used to implement the storage 
hierarchy prototype. The last section describes the implementation of the storage 


hierarchy interfaces. 


A. REQUIREMENTS 


The requirements for the storage hierarchy prototype are derived from two 
sources: a functional specification and a collection of general platform-related 
requirements. A functional specification of the storage hierarchy is located in section 
14.5.1 of the TCX LPSK Product Functional Specification (see Appendix) and includes a 
list of twelve requirements [14]. These twelve requirements are identified and discussed 
in the next section, followed by a section addressing an additional set of general 
requirements that inform the design of the storage hierarchy prototype developed in this 


thesis. 


i. Storage Hierarchy Functional Specification 


The TCX LPSK Product Functional Specification details the functional 
requirements of the LPSK. Section 14.5.1 of this specification lists twelve requirements 
for the organization of secondary storage data segments (hereafter referred to as data 


segments). The following list paraphrases these requirements: 


1. Data segments are organized in a tree-like hierarchy, where nodes of the tree 


represent data segments. 


2. The root of the tree is a node named ‘/’ and is not used to represent a data 


segment. 
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3. Nodes shall have any number of child nodes up to a configured maximum 


defined when the secondary storage media is formatted. 


4. Nodes are identified by a name consisting of any number from zero up to some 


configured maximum minus one. 


5. The name of a data segment is the list of node names from the root node to the 


specified data segment. 
6. Data segments are limited in size to ye bytes (4 GB). 
7. The “/0” node and its children are reserved for internal use by the LPSK. 


8. Only software that runs in a non-LPSK context may create data segments in the 


storage hierarchy. 


9. A message authentication code is generated and saved for a data segment 
whenever it has been created by configuration software or when a data 
segment in primary memory is flushed to the corresponding data segment in 


secondary storage during LPSK runtime. 


10. The integrity of data segments is verified by the LPSK whenever a data 
segment is swapped into primary memory from secondary storage. Failure in 
verification will result in some action according to the context of the system 


when verification is attempted. 


11. The LPSK Initializer provides data segment selectors to subjects that have 


been configured to access those data segments. 


12. During runtime, subjects shall use selectors supplied by the LPSK to perform 


actions on data segments. 


The term “selectors” refers to a special token or handle a subject uses to identify 
which data segment the subject wishes to have some action performed on. The LPSK 
Initializer is an LPSK module that is responsible in part for creating and supplying the 
appropriate selectors to the appropriate subjects, based on the configuration of the LPSK 


system. 
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The first five requirements taken together prescribe the tree-like structure of the 
storage hierarchy discussed in Chapter I. In that discussion, a node of the tree is 
described as either a data segment node or directory node. Early design decisions resulted 
in this unnecessary and unspecified distinction in a node’s type. This exclusive treatment 
of nodes is imposed by the model of the storage hierarchy developed in this thesis and is 
not a restriction derived from the listed requirements. Eliminating this distinction would 
allow an inner node (a node that has child nodes) to be a data segment. In the file system 
analogy, this lack of distinction is equivalent to allowing the creation of directories and 
subdirectories as files that may also contain files. The storage hierarchy model described 
in this thesis does not allow the overloading of nodes—resulting in nodes that are both 
data segment nodes and directory nodes—to avoid cognitive dissonance arising as a 
result of the storage hierarchy to file system analogy. These five requirements and the 
overall structure of the storage hierarchy are achieved through the creation of directory 


table data structures, which are discussed in detail in a subsequent section. 


The sixth listed requirement relates to the storage of a data segment’s size in bytes 
as an unsigned 32-bit integer value. The seventh listed requirement designates a special 
sub-tree of the storage hierarchy that contains data segments used internally by the LPSK. 
These segments are not made available to external subjects (subjects executing in LPSK 
partitions). The storage hierarchy is not responsible for enforcing this policy however, 
and relies on the LPSK initialization process to restrict selectors for internal use from use 


by external subjects. 


The eighth listed requirement, that only software that does not run as part of the 
LPSK system may create data segments, leads to the need for an offline storage hierarchy 
configuration tool. While such a tool is outside the scope of this thesis, the storage 
hierarchy prototype must include documented external interfaces to allow such a tool to 
modify the structure and contents of an LPSK storage hierarchy. These configuration 
interfaces should be executable on the same operating system the configuration tool runs 
on, such as the open source Linux operating system. These external interfaces are 


identified in Section B of this chapter. 
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The ninth and tenth listed requirements call for the creation and maintenance of 
message authentication codes (MAC) for each data segment in the storage hierarchy. A 
MAC is generated based on the contents of a data segment and a MAC key known by the 
LPSK, and is stored in the metadata associated with the data segment. The MAC for a 
given data segment is updated every time the contents of that data segment changes in a 
permissible context, e.g., during configuration or when a data segment is swapped out to 
the storage hierarchy during LPSK system execution. If the contents of a data segment 
are modified in some other context, such that a new valid MAC is not generated, the 


LPSK will not permit that data segment to be read into primary memory. 


The last two requirements prescribe the process of providing and using data 
segment selectors. The LPSK provides subjects zero or more selectors based on the 
configuration of the system. In addition to memory management of segment data, 
subjects may use these selectors as the target of swap in, swap out, and flush system calls. 
These requirements are achieved during initialization of an LPSK system by creating a 
database that maps selectors to data segments, and providing storage hierarchy runtime 
interfaces that accept selectors as parameters. These interfaces and the selector to data 


segment database are described in Section B of this chapter. 


2. Additional Storage Hierarchy Requirements 


All software developed for the TCX LPSK project must adhere to a set of 
standards described by the Software Development Standards document, a product of the 
Center for Information Systems Security Studies and Research (CISR). This document 
specifies that an ANSI-C compliant programming language is to be used when 
programming kernel code [15]. Any storage hierarchy related code that is executed 
during LPSK initialization or runtime must therefore be developed with the C 
programming language. 

The LPSK binary (the executable LPSK machine code) must be compiled by the 
Open Watcom C compiler [16]. This compiler was chosen over other open source 
compilers—such as the GNU Compiler Collection [17]—because it supports a large 


memory model [18]. Storage hierarchy configuration interfaces, however, are not 
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included in the LPSK binary due to previously enumerated requirements, and are not 


necessarily restricted to compilation by the Open Watcom compiler. 


The storage hierarchy will interact with its storage medium via a hardware 
abstraction layer (HAL). A HAL hides a particular device’s architecture and presents a 
set of interfaces common to the overall class of devices, such as hard disk drives. This is 
a necessary requirement as no hard disk device drivers have been developed for the 
LPSK at the time of this writing. Testing the storage hierarchy prototype required a 
special construct located in a test system’s memory or secondary storage that mimics an 
LPSK storage hierarchy’s storage medium. A standardized HAL makes it possible for the 
storage hierarchy prototype to communicate with both the special testing construct and 


future LPSK hard disk driver software. 


B. DESIGN 


The design of the storage hierarchy prototype attempts to satisfy the requirements 
identified in the previous section. Golden and Pechura’s description of a hierarchical file 
system is used as the basis for the design of the storage hierarchy’s internal structure [11]. 
This section describes both the internal structure of storage hierarchy constructs and the 


various interfaces used to interact with the storage hierarchy. 


Figure 4 provides an overview of the users of storage hierarchy interfaces and 
how those interfaces are organized in relation to the storage medium. The LPSK makes 
use of both initialization and runtime interfaces, while a configuration tool accesses the 
storage hierarchy by the configuration interface. These interfaces oftentimes share 
common algorithms and methods of storage hierarchy access that are identified as the 
“Common Components” of the storage hierarchy. The bottom layer of the logical layout 
of interfaces depicts the hardware abstraction layer interacting with the storage medium 
by way of middleware. This middleware comprises the device drivers and specifically 
written programs that translate HAL commands into actionable storage medium 
read/write instructions. These interfaces are described in detail after a description of the 


storage hierarchy’s internal structures. 
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Figure 4. Storage hierarchy logical interface layout. 


1. Internal Structure 


The storage hierarchy organizes data segments in two ways. The first is by the 
physical location of data segments across the storage medium on which the storage 
hierarchy resides. The second is by data segments’ logical locations within the tree 
structure of the storage hierarchy. Both kinds of organization are achieved with data 


structures that are stored together with the data segments on the storage medium. 


LPSK systems may be periodically taken offline for maintenance and 
configuration. As the resource needs of subjects change, system operators may wish to 
modify an LPSK system’s storage hierarchy by creating or removing data segments 
during these periods of maintenance. Section 12 of the LPSK functional specification, 
entitled “LPSK Offline Manager,” reinforces this notion of an evolving storage hierarchy 
configuration: “The LPSK Offline Manager shall provide a user interface to manage 
existing secondary storage segments, including the display, deletion, initialization, 
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duplication, movement, backup, and restoration of segments [14].” The LPSK Offline 
Manager is a configuration tool that uses the storage hierarchy configuration interfaces to 


modify a storage hierarchy. 


a. Physical Organization & Clustering 


The concept of partitioning a storage medium’s space into a number of 
blocks, or clusters of disk sectors in the case of hard disk drives, was introduced in 
Chapter II. The storage hierarchy interacts with an abstract view of its storage medium by 
reading and writing clusters. These clusters are the logical file system “blocks” described 
by Golden and Pechura, and are comprised of eight disk sectors of 512 bytes each for a 
total of 4 kilobytes per cluster. In Chapter II, an example file was shown to be allocated 
across noncontiguous blocks of a file system. Similarly, data segments are physically 
allocated across contiguous or noncontiguous clusters of a storage medium. The 
constituent clusters of a data segment are recorded in a data structure that organizes the 


physical location of all data segments of a storage hierarchy. 


The physical location of a cluster of the storage medium refers to its 
location in the logical span of sectors presented by the storage medium. This span of 
sectors and the collection of sector clusters are both ordered sets upon which an index is 
imposed. Figure 5 illustrates this concept using two-sector sized clusters for the sake of 
brevity. In this example, the storage hierarchy begins grouping sectors into clusters 


beginning at an arbitrary offset of four sectors from the beginning of the storage medium. 


Sectorindax 0 1 7 3 4 5 6 F 8 39... n-1 n 
Offset of first duster 
CGusterindax 0 1 2 n 
Figure 5. Logical view of storage medium and two-sector cluster assignment 
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A cluster’s location is found by adding the cluster offset to the product of 


the cluster’s index and the number of sectors per cluster: 


cluster location = of fset of first cluster + (cluster index x sectors per cluster) 
Using this equation, the third cluster can be found beginning at sector index eight. 


b. Segment Allocation Table 


The segment allocation table (SAT) is the storage hierarchy internal data 
structure responsible for the physical organization of data segments on the storage 
medium. It is a table that records the allocation status of every cluster of the storage 
medium assigned to the storage hierarchy. The allocation status of a given cluster 
represents one of three states: unallocated, allocated, or allocated and terminal. 
Unallocated clusters are available for allocation to data segments created during 
configuration, while allocated clusters are used to store all or part of a data segment. If a 
given cluster is allocated but not terminal, there is an additional cluster allocated to the 
same data segment. The SAT stores the index value for this next cluster in the “Next 
Cluster Index” field. Looking up the SAT row that corresponds to this next cluster index 
reveals its allocation status and potentially the SAT index of yet another cluster. In this 
way a list or chain of clusters can be read from the SAT by recursive lookup based on the 
index value for the first cluster allocated to a data segment. A cluster that has a status of 


allocated and terminal is the last cluster of the chain. 


Figure 6 illustrates an example SAT where three clusters have been 
allocated to two data segments. The first cluster at index zero is allocated to a data 
segment and is that data segment’s only cluster. The cluster at index one is marked as 
allocated but not terminal. The “Next Cluster Index” field shows that the next cluster in 
the chain can be found at SAT index two. Looking up the cluster at SAT index two 


reveals that this cluster is last in a two-cluster chain. 
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SATIndex Allocation Status NextClusterIndex 


0 alloc. & terminal 
1 [allocated 
2 alloc.&terminal | QQ | 


n unallocated a 





Figure 6. Example segment allocation table. Omega denotes empty SAT index value. 


A SAT entry is comprised of a 2-bit field that contains the allocation 
status of a cluster and a 30-bit field that contains the SAT index of the next cluster. Table 


1 contains the hexadecimal values for the allocation status field. 























Status Value 
Unallocated 0x0 
Allocated Ox1 
Allocated & Terminal | 0x2 





Table 1. Allocation Status field values. 


The SAT data structure is located on the storage medium in reserved 
space, before space designated for storing data segments. During LPSK system 
initialization, cluster chains belonging to data segments which have been made known 
are parsed from the SAT and loaded into memory. During configuration, the SAT is 
modified to reflect the creation or deletion of data segments. Both of these activities 
require a priori knowledge of the SAT index for the first cluster of every data segment. 
This information is stored in a metadata structure that describes the logical layout of data 


segments in the tree-like structure of the storage hierarchy, which is described next. 


é Directory Table 


Directory table data structures are used to reference and organize data 
segments in terms of the logical hierarchy of the storage hierarchy. A directory table 
exists for each parent node of the tree and is used to record information about child 


nodes, including each child node’s first cluster SAT index, actual size in bytes, and other 
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metadata. If a parent node has ten child nodes, its directory table will contain ten rows. 


Table 2 describes the type and size of the fields of the directory table structure. 





























Directory Table 
Byte Offset | Size (in bytes) Description 
0x00 4 Name of node 
0x04 4 First SAT index 
0x08 4 Actual size (in bytes) 
0x0C 32 256-bit hash (MAC) 
0x2C 1 Type flag (parent or data segment) 











Table 2. _ Directory table structure description. 


The name of a node is an unsigned 32-bit integer from zero up to the 
preconfigured maximum specified during configuration of the LPSK system. The first 
SAT index field contains the index of the row of the SAT that refers to a data segment’s 
first cluster. With this information gathered from a directory table entry, SAT cluster 
chains can be parsed and data segments located on the storage medium. The size of data 
segments may not necessarily be a multiple of the storage hierarchy cluster size. 
Therefore the actual data segment size as specified during configuration is stored to 
inform storage hierarchy interfaces when to ignore the unused portions of clusters. A 


256-bit field is used to store the MAC generated to ensure data segment integrity. 


The last field of the directory table brings about an important result: 
Directory table structures are stored in the storage hierarchy in the same way as data 
segments. The type flag field determines if a child node is treated as a data segment or a 
directory table node by the storage hierarchy. If the type flag is set to “data segment,” the 
node referenced is a leaf node containing a data segment. If the type flag is set to 
“parent,” the child node contains a directory table structure. The unsigned integer value 
Ox1 denotes a data segment node while the value 0x2 denotes a directory table node. 
Directory tables are special internal storage hierarchy segments that are never revealed 
externally. Directory tables may consume more than one cluster in the same manner that 
data segments do. This occurs if the configured maximum number of child nodes per 
directory node exceeds the number of directory table rows that can be stored on one 


cluster. 
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Each cluster of a directory table contains an additional structure used to 
store directory table row statistics and the information necessary to follow directory table 
cluster chains. Table 3 describes the purpose and size of this data. A flag indicates if the 
directory table is continued in an additional cluster. If it is, the next cluster’s SAT index 
is stored. The total number of table rows a directory table cluster contains is also stored, 
along with the current number of unused rows in that cluster. A summation of unused 
rows over all clusters of a directory table is updated and retrieved from the first cluster of 
the overall directory table cluster chain. By maintaining this information storage 
hierarchy modules can be prevented from performing futile searches for free directory 


table rows when there are no unused rows available. 





Directory Table Cluster Information 


























Byte Offset | Size (in bytes) Description 

0x00 4 Total number of directory table rows 

0x04 4 Number of free, unused rows in this cluster 

0x08 4 Overall number of unused rows in all clusters used for 
directory table 

0x0C 4 SAT index of next directory table cluster 

0x10 1 More clusters flag 








Table 3. _ Directory table cluster information structure description 


The root of the storage hierarchy tree is represented by a directory table 
that always begins at cluster index zero. This convention provides a static entry point into 
the storage hierarchy from which all other directory tables and data segments can be 
located. Figure 7 demonstrates a simple storage hierarchy layout that shows the ‘/’ root 
node’s two children, one of which is a data segment and another which is a directory 


table node. The directory table node “/5” has two children itself, both data segments. 
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Data segment: /2 







Data segment: /5/1 Data segment: /5/2 


Figure 7. Example logical storage hierarchy layout with directory tables 


Directory tables are created and modified during storage hierarchy 
configuration. They are written to clusters on the storage medium at this time, and may 
subsequently be rewritten as new child nodes are added to particular parent nodes. During 
LPSK system initialization, data segments are located by following the paths created by 
the linking of directory tables, as shown in Figure 6. 


d. Other Storage Hierarchy Databases 


A storage hierarchy contains several other data structures used internally 
to maintain state and configuration information. This data is stored on the storage 
medium in data blocks located before the SAT. Table 4 shows the first of these data 
structures, which contains information about the layout of the storage hierarchy on the 
storage medium. The first three fields contain the location of other storage hierarchy 
databases in terms of their offset into the logical span of the storage medium. The storage 
hierarchy cluster size is also defined along with the size of the SAT and the maximum 
number of child nodes per directory node allowed. This data structure is written when an 


LPSK system’s storage medium is first formatted in preparation for configuration. 
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Static Configuration Data 






































Byte Offset | Size (in bytes) Description 

0x00 4 Offset from start of storage medium to SAT 

0x04 4 Offset from start of storage medium to first cluster 

0x08 4 Offset from start of storage medium to Cluster database 

0x0C 4 Cluster size in number of 512-byte blocks 

0x10 4 The size of the SAT in number of 512-byte blocks 

0x14 4 The number of SAT rows 

0x18 4 The maximum number of child nodes per directory node 
Table 4. Static Configuration data structure description 


An additional data structure maintains a count of the state of storage 


hierarchy clusters, including how many clusters are allocated and unallocated. By 


keeping a count of the total number of free clusters available for allocation, storage 


hierarchy interfaces do not have to scan the entirety of the SAT to determine if there are 


enough free clusters every time a new data segment is created. A separation of allocated 


cluster counts based on what type of data clusters contain—data segments or directory 


tables—provides some insight into the amount of metadata overhead present in the 


storage hierarchy, but this information is not required or used by any interfaces. Table 5 


enumerates this cluster accounting data structure. 























Cluster Values 
Byte Offset | Size (in bytes) Description 
0x00 4 Total number of clusters 
0x04 4 Free/Unallocated clusters 
0x08 4 Clusters allocated to data segments 
0x0C 4 Clusters allocated to directory tables 














Table 5. — Cluster values data structure description. 


e. Handle Table 


The handle table data structure is distinct from all previously discussed 


data structures in that it only exists in the primary memory of an LPSK system. The 


handle table is constructed during LPSK initialization and associates handles, or data 


segment selectors, to particular data segments of the storage hierarchy. Data from the 
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handle table is used during runtime, after initialization, to perform operations on 


secondary storage data segments. Table 6 displays the contents of this data structure. 





























Handle Table 
Byte Offset | Size (in bytes) Description 
0x00 4 Handle 
0x04 4 Size (in bytes) 
0x08 4 First SAT index 
0x0C 4 Parent’s first SAT index 
0x10 4 Directory table index 











Table 6. | Handle table data structure description. 


The relevant information of every secondary storage data segment to be 
made known in an LPSK system, is recorded in the handle table data structure. This 
information includes the handle by which the LPSK refers to a particular data segment, 
the data segment’s size in bytes, and the SAT index of its first cluster. This information 
facilitates the reading and writing of data segments from the storage hierarchy. The SAT 
index of the first cluster of a data segment’s parent is also recorded, along with the index 
within the directory table that refers to that data segment. This information allows storage 
hierarchy interfaces to read and update metadata, such as a data segment’s MAC, during 


runtime. 


The next section describes the interfaces the LPSK and configuration tools use to 


access the internal data structures described in this section. 


2: External Interfaces 


As a module of the overall LPSK, the storage hierarchy makes its services 
available through a number of external interfaces. These interfaces are said to be external 
because they are designed to be used by other modules of the LPSK. The availability of 
these external interfaces depends on the three distinct modes of an LPSK system: 
configuration, initialization, and run-time. In configuration mode, the storage medium on 
which the storage hierarchy resides is attached to and modified by a non-LPSK system 


running configuration software. During initialization mode, the storage hierarchy is 
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prepared for operation by an interface that constructs a handle table data structure in 
primary memory which records all data segments exported to system subjects and data 
segments used internally by the LPSK. Data segments may also be swapped in during 
this mode. In the run-time mode, the storage hierarchy exposes interfaces used to flush, 


swap in, and swap out data segments from secondary storage. 


The technical specification of the external interfaces (see Appendix A) 
categorizes interfaces based on the mode of system operation for which they are meant to 


be used. 


a. Configuration Interfaces 


The configuration interfaces of the storage hierarchy are used to construct 
the layout of a storage hierarchy on a storage medium and populate it with data segments. 
The collection of configuration interfaces provides the application programming interface 
(API) that is used by storage hierarchy configuration tools. The thirteen individual 


interfaces are listed in categories that reflect their usage. 
Storage hierarchy layout interfaces: 


e initialize_databases: Loads storage hierarchy 
configuration, cluster, and SAT databases into primary memory 
from the storage medium. 


e make_dseg: Creates a data segment node off of a parent node. 


e del_dseg: Removes a data segment node and zeros out its 
associated clusters. 


e make_subtree: Creates a directory table node off of a parent 
node. 


e del_subtree: Removes a parent directory node and all of its 
child nodes of all types. This interface descends a sub-tree 
beginning at the specified directory table node, removing all 
descendent nodes. 


e get_child: Returns the names and node types of the specified 
parent’s child nodes. A _ configuration tool can effectively 
enumerate a storage hierarchy’s layout using this interface. 
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Data segment access interfaces: 


e open_dseg: Returns a handle associated with a data segment that 
is used by other interfaces to access the contents of data segments. 


e write_dseg: Writes data into the data segment associated with 
the supplied handle. 


e read_dseg: Reads data from a data segment associated with the 
supplied handle. 


e close_dseg: Generates a new MAC for the data segment 
associated with the handle then purges that handle from the handle 
table. 


Data segment metadata interfaces: 


e get_dseg_size: Returns the actual size of a data segment. This 
interface may be used by a configuration tool to learn how large a 
buffer to allocate in primary memory prior to reading the contents 
of a data segment. 


e check_hash: Compares an integrity hash of the contents of a 
data segment with the MAC stored in that data segment’s 
metadata. 


b. Initialization Interfaces 


The initialization interfaces of the storage hierarchy are used to construct 
and populate the handle table data structure prior to LPSK runtime. Interfaces used to 


accomplish the swap in operation are also provided. 


e initialize_databases: Loads storage hierarchy 
configuration, cluster, and SAT databases into primary memory 
from the storage medium. Initializes an empty handle table in 
memory with as many rows as necessary to record the specified 
number of handle to data segment associations. 


e get_handle: Loads the specified data segment’s meta-data into 
the handle table database and returns a handle to be used for future 
operations on that data segment. 


e read_in: Loads the data segment associated with the specified 
handle from the storage hierarchy storage medium into the 
specified buffer in primary memory. This interface supports the 
swap in operation. 
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Cc. 


get_dseg_size: Returns the size of the data segment 
associated with the specified handle. 





get_dseg_hash: Returns the MAC value stored in the meta- 
data of the data segment associated with the specified handle. 


Runtime Interfaces 


The storage hierarchy runtime interfaces are used by the LPSK to perform 


swap in, swap out, and flush actions on data segments. Both swap out and flush 


operations are accomplished using the same interface as they have the same effect from 


the perspective of the storage hierarchy. With the exception of the write_out 


interface, all runtime interfaces behave the same as their initialization interface 


counterparts. 


read_in: Loads the data segment associated with the specified 
handle from the storage heiarchy storage medium into the specified 
buffer in primary memory. 


write_out: Writes the data segment from primary memory 
associated with the specified handle from the specified buffer, then 
calculates and stores the new data segment MAC. This interface is 
used by the swap out and flush operations. 


get_dseg_size: Returns the size of the data segment 
associated with the specified handle. 





get_dseg_hash: Returns the MAC value stored in the meta- 
data of the data segment associated with the specified handle. 


3. Hardware Abstraction Layer 


The storage hierarchy HAL is designed to provide an abstract and simple view of 


the storage medium. It provides the interfaces to the storage medium used to read and 


write clusters, SAT data, and storage hierarchy configuration databases. 


e read_cluster: Reads the specified cluster into memory. 


e write_cluster: Writes data to the specified cluster. 


e read_dir: Reads the specified cluster containing a directory table 
structure into memory. 


e write_dir: Write a directory table structure to the specified cluster. 
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e read_blocksize: Read a disk block-sized data structure into memory. 


e write _blocksize: Write a disk block-sized data structure to disk 





C. IMPLEMENTATION METHODOLOGY 


The storage hierarchy external interfaces and common components were 
developed in ANSI-C89 standard programming code with the assistance of the Apache 
Software Foundation licensed Eclipse Platform. The Eclipse Platform is an integrated 
development environment that provides various features to assist developers in the rapid 
development and compilation of code. An Eclipse project is the collection of program 
source files and additional internal databases that contain meta-data about various aspects 
of the program. Eclipse recognizes and records program function and variable names and 
structures in its databases as they are authored to provide helpful functionality to 
programmers. Such functionality includes auto-completion of C structure members and 
generation of function call hierarchies. The development and testing platform consisted 
of a Fedora Linux (kernel version 2.6.31.5) workstation. The GNU Compiler Collection 
(GCC) C compiler was used to produce binary executable modules of storage hierarchy 
configuration interfaces and common components for the purposes of testing their 


functionality and correctness. 


An Eclipse C project was created as a collection of C program source and header 
files that together incorporate the storage hierarchy external interfaces and common 
components. C pre-processor conditional directives embedded within each module 
determine if module functions are compiled as part of a configuration tool or the LPSK 
binary. The distinction between LPSK and non-LPSK context modules and functions is 


described later in this section. 


1. Storage Medium Construct 


The storage hierarchy prototype requirements call for a test construct located in 
primary memory or secondary storage of a test machine that mimics the storage 
hierarchy’s storage medium. This simulated storage medium is necessary during 
development and testing of the prototype to ensure the common components used by 


external interfaces correctly read and modify hierarchy structures. It is also possible to 
a2 


test for storage hierarchy structure and data segment permanence and retrievability if the 


construct is located on the test machine’s secondary storage. 


The special construct was created using a virtual hard disk drive which is attached 
to the test machine as a raw, unformatted disk device. The Unix system command line 
tool dd is used to read and write from the virtual disk. The dd tool allows reading and 
writing raw binary data from block I/O devices without regard for file systems or 
partitioning conventions. The storage hierarchy prototype hardware abstraction layer 
implementation invokes the dd tool by constructing a command line string and calling the 
C library function popen (). This function executes the supplied string as a Linux shell 
command and returns a file stream from the process. The arguments supplied to dd 
through the command line string tell dd where to read and write from the disk device. 
Figure 8 depicts the sequence of C instructions that accomplishes this. 


FILE *fpipe = popen("dd of=/dev/sdb bs=512 seek=10 count=1", "w"); 
int result = fwrite(buffer, 512, 1, fpipe); 


Figure 8. Example HAL dd string that writes a block of 512 bytes from the pointer 
buffer to the device /dev/sdb 


D. IMPLEMENTATION 


The storage hierarchy interface prototypes developed in this thesis are compiled 
and linked based on which external software program uses them. When interfaces are 
used by the LPSK binary, those interfaces are said to be executed in an LPSK context. 
The configuration interfaces execute in a non-LPSK context during the configuration of 
an LPSK system and contain the program logic necessary to perform all storage hierarchy 
maintenance operations. The initialization and runtime interfaces execute in the LPSK 
context and perform a subset of these operations. Both storage hierarchy interface 
contexts share common components such as helper functions and data structures. These 
functions and data structures are used by the interfaces to perform common operations, 
such as navigating the storage hierarchy tree structure, or retrieving data segment meta- 
data. The module dependencies of both interface contexts are introduced next, followed 


by a description of the common components. 
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i, Configuration Interface Implementation 


Figure 9 illustrates the module dependencies of the storage hierarchy 
configuration interfaces and common components. Each diagram element represents a C 
program module. The common components consist of the modules used by the 
configuration interfaces. Modules are layered in terms of their dependencies. For 
example, several configuration interfaces depend on the handle table manager module to 
provide data segment handles. The handle table manager in turn depends on the directory 
manager and SAT manager modules to retrieve directory table structures and meta-data 
associated with the desired data segment. These two modules depend on the HAL 


module, which interfaces with the storage hierarchy’s storage medium. 


Configuration Interfaces 


Configuration Cluster Handle Table 
Database Database Manager 


Manager Manager ; 
SAT Manager Directory Manager 


Hardware Abstraction Layer 


Figure 9. Configuration interface module dependency diagram. 





2. Initialization and Runtime Interface Implementation 


Figure 10 illustrates the module dependencies of the storage hierarchy 
initialization and configuration interfaces and common components. In contrast to the 
configuration interface dependency diagram, the initialization and runtime interfaces no 
longer have direct access to the SAT and directory manager modules, and may only 
interact with the limited facilities provided by the handle table manager. The cluster 
database manager is excluded entirely, as the statistics it maintains are useful only in the 
creation and deletion of data segments and directory structures. This reduction in 
modules reflects the reduction in the scope of storage hierarchy operations performed by 


these interfaces. 
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Initialization & Runtime Interfaces 


Configuration Handle Table Manager 


Database 


Manager SAT Manager Directory Manager 


Hardware Abstraction Layer 


Figure 10. Initialization and Runtime interface module dependency diagram including. 





3. Common Components 


The storage hierarchy common components consist of six individual C program 
modules that maintain data and perform actions necessary for the operation of various 
interfaces. Each module function is identified by which context it is used. Each module is 


described in detail in the following sections. 


a. Configuration Database Manager 


This module is responsible for maintaining the configuration database in 
memory, providing functions to retrieve configuration data that describe the layout of 


data structures on the storage medium, and the dimensions of certain constructs. 
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Config _db.c external functions 










































































Name Description Context 

init_config_db Loads the configuration database into memory from | Both 
disk. 

get_SAT_offset Returns the block offset value to the beginning of the | Both 
Segment Allocation Table database on disk. 

get_cluster_offset Returns the block offset value to the beginning of the | Both 
storage medium where data segments and directory 
table clusters are located. 

get_cluster_size Returns the size of clusters in number of 512-byte | Both 
disk blocks. 

get_cluster_db_offset | Returns the block offset value to the cluster database | Both 
structure on disk. 

get_SAT_size Returns the size of the Segment Allocation Table in | Both 
terms of 512-byte disk blocks. 

get_SAT_records Returns the number of 32-bit rows in the SAT Both 

get_MAX_children Returns the maximum number of children per | Both 





directory node as defined by an LPSK configuration 
vector 








Table 7. 


Configuration database manager external functions description. 


b. Cluster Database Manager 


This module is responsible for maintaining the cluster database in memory 


and providing functions to retrieve and update cluster values. Cluster usage values are 


used by configuration interfaces only. 
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cluster _db.c external functions 


















































Name Description Context 
init_cluster_db Loads the cluster database into memory from disk. Non- 
LPSK 
get_free_clusters | Returns the number of free clusters available in the | Non- 
storage hierarchy. LPSK 
inc_dseg_clusters | Increases the data segment cluster value by the specified | Non- 
amount and decreases the free cluster value by the same | LPSK 
amount, writes the cluster database to disk. 
dec_dseg_clusters | Decreases the data segment cluster value by the specified | Non- 
amount and increases the free cluster value by the same | LPSK 
amount, writes the cluster database to disk. 
inc_dir_clusters | Increases the directory table cluster value by the specified | Non- 
amount and decreases the free cluster value by the same | LPSK 
amount, writes the cluster database to disk. 
dec_dir_clusters | Decreases the directory cluster value by the specified | Non- 
amount and increases the free cluster value by the same | LPSK 





amount, writes the cluster database to disk. 








Table 8. Cluster database manager external functions description. 


G Directory Manager 


This module provides functions related to the storage and access of 


directory table structures and node records. Functions are provided that allow iteration 


along a path in the storage hierarchy, search for the records of particular data segment 


and directory nodes, and retrieval of data segment metadata. 





directory _mgr.c external functions 
































Name Description Context 

dir_retrieve_dir Populates the supplied directory table structure in | Both 
memory from a directory table cluster at the 
specified SAT index from disk. 

dir_write_dir Writes a directory table structure to the cluster at the | Both 
specified SAT index on disk. 

dir_retrieve_record | Returns a directory table record associated with the | Both 
specified node from the supplied directory table 
structure in memory to the caller. 

dir_retrieve_record_ | Returns a directory table record associated with the | Both 

and_index specified node from the supplied directory table 
structure in memory. It also returns the index in the 
directory table where the record was found. 

dir_check_node_ Returns TRUE if the specified node is found in the | Both 

Presence directory table cluster chain headed by the directory 
table referenced by supplied pointer. 

dir_get_hash Returns the hash value of the specified node from its | Both 





directory table record. 
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directory_mgr.c external functions 







































































Name Description Context 
dir_get_size Returns the size of the specified data segment node Both 
dir_rtr_dir_by_path | Returns the node type and SAT index of the last | Both 
node of the supplied path after it has walked through 
the storage hierarchy tree according to the supplied 
path string. 
dir_update_hash Updates the 256-bit hash of the data segment located | Both 
in the specified row of the supplied directory table 
with the supplied hash. 
dir_get_type Returns the node type of the specified node. Non- 
LPSK 
dir_new_directory Creates a new directory table structure in memory. Non- 
LPSK 
dir_delete_record Removes the record associated with the specified | Non- 
node from the supplied directory table. Returns the | [PSK 
SAT index of the node’s first cluster 
dir_get_nth_record Returns the node name and type of the n’th occupied | Non- 
row of the supplied directory table. LPSK 
dir_rtr_node_SAT_ Returns the SAT index of the specified node’s first | Non- 
index cluster from the supplied directory table. LPSK 
dir_ins_record_and__ | Inserts a new node record into a directory table | Non- 
commit structure and writes associated directory table | [PSK 
clusters to disk. 
dir_get_num_free_ Returns the number of free records (and therefore | Non- 
Records child nodes that can be created) for a directory table | [PSK 
structure cluster chain headed by the directory table 
referenced by supplied pointer 
Table 9. Directory manager external functions description 
d. Handle Manager 


This module is responsible for maintaining the handle table manager in 


memory. The handle table is used in both code bases to associate a data segment with a 


handle that is then used for read/write operations. 
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Handle_mgr.c external functions 





Name Description Context 





init_handle_manager | Constructs a dynamically sized handle-to-data segment | Both 
table in memory. 





get_handle Loads a data segment’s pertinent meta-data into the | Both 
handle table and returns a handle used to reference that 
data segment. 





delete_handle Purges a handle table row from the handle table. Both 





write_to_handle Retrieves meta-data from the handle table row | Both 
associated with the specified handle and calls SAT 
manager module to write to the storage medium. 








read_from_handle Retrieves meta-data from the handle table row | Both 
associated with the specified handle and calls SAT 
manager module to read from storage medim. 























get_handle_size Returns the size of the data segment associated with the | LPSK 
specified handle. 

get_handle_hash Returns the 256-bit hash value of the data segment | LPSK 
associated with the specified handle 

calc_hash Calculates and returns the hash value of the contents of | Both 
the data segment associated with the specified handle. 

update_hash Updates the 256-bit hash of the data segment associated | Both 








with the specified handle. 





Table 10. | Handle table manager external functions description. 


e. SAT Manager 


This module is responsible for maintaining the Segment Allocation Table 
in memory and providing functions to allocate and unallocate cluster chains, and read and 
write the SAT to the storage medium. It also provides functions to read and write clusters 


and data segments from the storage medium. 
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SAT_mgr.c external functions 



































Name Description Context 

sat_init Loads the SAT into memory. Both 

sat_alloc_clusters Creates a cluster chain of the specified size by setting | Non- 
allocation status and next SAT index values. | LPSK 
Commits SAT changes back to disk. Returns the SAT 
index of the head of the chain. 

sat_unalloc_clusters | Destroys a cluster chain starting at the specified SAT | Non- 
index by resetting the allocation status for each | LPSK 
member of the chain. Commits SAT changes back to 
disk. Returns the number of SAT rows 

sat_get_next Returns the next SAT index value of the specified | Both 
SAT index. 

sat_read_cluster Reads the cluster with the specified SAT index into | Both 
memory. 

sat_write_dseg Writes data from the specified buffer to the data | Both 
segment located with the specified handle on the 
storage medium. 

sat_read_dseg Reads data from the data segment associated with the | Both 








specified handle from the storage medium into the 
specified buffer. 








E. 


Table 11. . SAT manager external functions description. 


SUMMARY 


This chapter introduced the requirements of the storage hierarchy prototype and 


presented a design. The implementation methodology was discussed and the external 


interfaces and common component external functions were enumerated. The next chapter 


contains test procedures and results for the external interfaces. 
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IV. TESTING 


This chapter presents an LPSK storage hierarchy scenario that is used to test the 
storage hierarchy prototype external interfaces. The results of each external interface test 


are grouped based on their interface category used throughout this work. 


A. TEST SCENARIO 


The test scenario consists of a 128-megabyte virtual disk that is pre-formatted to 
contain the prerequisite storage hierarchy configuration databases and segment allocation 
table. This relatively small virtual disk size (compared to modern disk drives) was chosen 
to make test cases involving disk space limitations easier to construct. The disk is 
formatted by a program that utilizes its knowledge of storage hierarchy structures and the 
storage hierarchy HAL interface to write these databases, SAT, and directory tables to 
disk before configuration interfaces are used. The specific data used to create the 
formatted test disk are described next, followed by a brief description of the programs 


that simulate a storage hierarchy configuration and LPSK interface user. 


1. Storage Medium Format 


Table 12 contains the configuration database values for the test storage hierarchy. 
The logical disk locations of various storage hierarchy data structures for the test scenario 
were chosen arbitrarily as storage hierarchy requirements do not describe the 


organization of data segments or meta-data on the storage medium. 
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Scenario Configuration Data 





















































Name Value Description 

SAT_ offset 10 Offset from start of storage medium to SAT 

first cluster_offset | 266 Offset from start of storage medium to first cluster 

cluster_db offset | 9 Offset from start of storage medium to Cluster database 

cluster_size 8 Cluster size in number of 512-byte blocks 

SAT size 256 The size of the SAT in number of 512-byte blocks 

SAT records 32,768 The number of SAT rows 

max_children 128 The maximum number of child nodes per directory 
node 











Table 12. Storage hierarchy test scenario configuration database data. 


The SAT begins at the tenth block of the virtual disk and spans 256 disk blocks. It 
contains a total of 32,768 rows. This SAT size is large enough to address a 128-megabyte 


storage medium space. The maximum number of child nodes is set to 128 nodes. 


Table 13 contains the cluster database values for the test storage hierarchy. 





Scenario Cluster Values 
Name Value Description 
total clusters | 32,768 | Total number of clusters 
free clusters | 32,766 | Free/Unallocated clusters 
dseg clusters | 0 Clusters allocated to data segments 
dir clusters | 2 Clusters allocated to directory tables 












































Table 13. Storage hierarchy test scenario cluster database values. 


The value for the total number of clusters matches the number of SAT rows from the 
configuration database, since each SAT row is mapped to a cluster. The free cluster value 
is two less, as two clusters are pre-allocated to the root directory node, which is always 
present in a storage hierarchy. The directory cluster value reflects the allocation of two 


directory clusters. 


Recall from Chapter III the directory table and directory table cluster information 
structures. The directory table cluster information structure, which is located on every 
cluster allocated for storage of directory tables, consumes 20 bytes. One row of a 


directory table structure consumes 48 bytes. The maximum number of directory table 
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rows per directory table cluster is found by subtracting the size of the directory table 
cluster information structure from the size of clusters in bytes, divided by the size of a 


directory table row: 


cluster size — directory cluster information size 


max directoryrows = - . 
directory row size 


Given a four kilobyte cluster size, the maximum number of directory table rows per 
directory table cluster is 84.916 . The remainder is ignored to yield 84 directory table 
rows per directory table cluster. Two directory table clusters are required to store the 
meta-data in order to accommodate the maximum number of child nodes, 128, permitted 


by the configuration. 


The root directory table is constructed from two directory table structures. The 
first directory table’s cluster total number of records value is set to 84. The more clusters 
flag is set to indicate that another directory table cluster follows. The location of the next 
directory table cluster is set to SAT index one. The maximum records value is set to 128 
to indicate how many directory table rows are available for use across all directory table 


clusters of the chain. Each directory table row is initialized to null values and their 











statuses are set to NODE_TYPE_FREE to indicate they are available for usage. The 
directory structure is then written to disk using a HAL interface. The second directory 
table cluster is constructed and written to disk at the next cluster in the same way. The 


cluster directory more flag is unset to indicate no more directory clusters follow. 


The segment allocation table is constructed as an array of 32-bit unsigned integers 
of length equal to the number of SAT rows value stored in the configuration database, 
plus one. The extra integer contains a special value that is used by the SAT_init function 
of the SAT manager module to ensure the binary data is has retrieved from disk during 


initialization represents a SAT. The SAT array is written to disk using a HAL interface. 


2. Test Programs 


Two test programs simulate both a storage hierarchy configuration tool and the 


LPSK. The configuration interface test program uses configuration interfaces to create 
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and modify the storage hierarchy structure on disk, read and write data segments, 
compare data segment hash values, etc. The LPSK test program uses initialization and 
runtime interfaces to get handles for data segments created during configuration and 
perform a sequence of read and write operations, comparing expected hash values with 
those stored in meta-data. The test programs record the return value for each interface 
call and any unexpected results it encountered when reading and writing data segments. 
In addition, both test programs make use of the format function provided by the 


program that returns the test storage hierarchy’s storage medium to its original state. 


Each test program is produced by invoking the storage hierarchy make file with a 
specific argument. A make file contains the compiler and linker directives and is 
interpreted by the Make utility to invoke the tools necessary to produce machine-code 
binary files. Make is part of the GNU Compiler Collection [17]. The config_test 
argument instructs the Make program to compile and link the configuration test program 
with the storage hierarchy configuration interfaces. The configuration test program 
performs each configuration group autonomously and can also be directed to perform 
some of the storage hierarchy configuration tasks required by the LPSK test program. 


Figure 11 illustrates the hierarchical dependencies of the configuration test program 


Configuration Test Program 
Configuration Interfaces 


Configuration Cluster Handle Table 


Database Database Manager 
Manager Manager 


SAT Manager _ |Directory Manager 


Hardware Abstraction Layer 


Figure 11. Configuration test program compiled with configuration interfaces and 
common components as a single monolithic executable. 
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The LPSK test program is produced by invoking the make file with the 
lpsk_test argument. The LPSK test program is linked with the storage hierarchy 
initialization and runtime interfaces, and performs the tests involving these interfaces. 


Figure 12 illustrates the hierarchical dependencies of the LPSK test program. 


The storage hierarchy interface calls that are performed by the test programs are 
reflected in each test group’s test procedure, found in Appendix B. Both test programs 
expect an argument with a value that corresponds to a specific test group, or a set of steps 
that make up part of a test group. When a test program is executed with a valid test 
instruction, it performs the test procedures associated with the specified test group and 
prints the results. To run the sh_c_make_dseg test procedure, for example, the 
configuration test program is first generated by invoking the storage hierarchy make file 
with argument test_config. The resulting executable file is then called with test 
group argument TEST_C2. Certain initialization and runtime interface test groups 


require that both test programs be called in sequence as described by the test procedure. 


LPSK Test Program 


Initialization & Runtime Interfaces 


Configuration Handle Table Manager 


Database 


Manager SAT Manager Directory Manager 


Hardware Abstraction Layer 


Figure 12. LPSK test program compiled with initialization and runtime interfaces and 
common components as a single monolithic executable. 
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B. EXTERNAL INTERFACE TESTING 


The storage hierarchy prototype external interfaces were tested through a series of 
“black-box” tests. Black-box testing relies on the documentation of the external interfaces 
to confirm whether or not they behave according to specification. Positive and negative 
tests are performed for each interface. Positive tests demonstrate that interfaces function 
correctly on valid input parameters. Negative tests demonstrate that the external 
interfaces return the expected error codes when invalid input or error states are 
encountered. The external interfaces are tested on the storage hierarchy-formatted virtual 
disk described in Section A. See Appendix B for the test plans used to produce the results 
that follow. 


Multiple tests were performed for each interface. Individual tests were labeled 
with a name and test type and are recorded in a table along with the relevant parameters 
supplied to the interface, the expected result of the interface, and a record of the observed 
behavior of the interface. Each test was performed independently of others except where 
indicated by the test naming scheme. Tests were named by their category (configuration, 
initialization, runtime), a unique test group number that distinguish different interfaces 
tests, and a sequence of capital letters that distinguished individual tests. When tests 
depend on and need to occur after previous tests, the capital letter remains the same and a 
sequentially increasing digit is affixed. For example, test C1A is the first test of a 
configuration interface, and test C2A is the first test of the next configuration interface. 
Whereas, tests labeled C1A.1 and C1A.2 imply that the results of the latter rely on the 


results of the former. 


Tests are categorized by their type, either positive or negative. Only interface 
parameters relevant to a specific test run are enumerated (See Appendix A for full list of 
external interface parameters). Parameters that are not meaningful for a specific test were 
omitted. In the case of positive tests, an interface return value indicating that no error has 
occurred is expected. Specific error codes are expected as the result of negative tests. 


Many interfaces that rely on previous storage hierarchy operations, te., the 


46 


sh_c_write_dseg interface cannot be tested for functional correctness unless a 
handle has been associated with a newly created data segment. Test prerequisites are 


described for these context-sensitive interfaces. 


1. Configuration Interface Testing 


Table 14 contains the results of test group 1, the 
sh_c_initialize_databases interface. The configuration database is located at 
block offset eight as described in Section A of this chapter.. Passing any other block 
offset value will cause the configuration database initialization function to fail. For test 
runs CIE and CIF, the block offset data stored in the configuration database was set to 


verify that the module correctly identifies the error. 


Table 15 contains the results of test group 2, the sh_c_make_dseg interface. 
These tests were performed after storage hierarchy databases and structures had been 
initialized. Table 16 contains the results of test group 3, sh_c_make_subtree 
interface. These tests were also performed after storage hierarchy initialization. A large 
data segment was created to consume all free clusters prior to test run C3C to generate 


the SH_C_DISKSPACE error code. 








Test group 4, the sh_c_open_dseg interface, requires the presence of data 
segments in order to perform meaningful functional tests. Table 17 contains the test 
results for this interface after the storage hierarchy was initialized and three data 
segments were created at paths “/1”, “/2”, and “/3”. The number of handle table rows in 


the configuration database was set to two during initialization to cause the 








SH_C_HANDLE_TABLE_FULL error code to be generated when sh_c_open_dseg is 


called for a third data segment. 
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Test group 1: sh_c_initialize databases 















































Test | Type Parameters Expected Result Pass? Remarks 

C1A | Pos. | block offset: 8 No error, database structures loaded. Pass_ | Offset 8 is the correct value 

C1B | Neg. | block_offset: 0 SH_C_CONFIG_DB LOAD ERR Pass 

CIC | Neg. | block_offset: 8 SH_C_CLUS_DB_LOAD_ERR Pass | Configuration database altered to 
reflect incorrect location of cluster 
database. 

C1D | Neg. | block_offset: 8 SH_C_SAT_LOAD_ERR Pass | Configuration database altered to 
reflect incorrect location of SAT 

















Table 14. Test group 1: sh_c_initilizase_databases. 
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Test group 2: sh_c_make_dseg 



























































Test | Type Parameters Expected Result Pass? Remarks 

C2A.1 | Pos. | path: “/” No error, data segment created Pass | Data segment node at path “/0” 
node: 0 created. 
size: 9000 

C2A.2 | Neg. | path: “/” SH_C_NODE_ALREADY_EXISTS Pass | Duplicate data segment node 
node: 0 from test C2A.1 detected. 

C2B_ | Neg. | path: “/” SH_C_MAX_NODE_NAME Pass | Specified node name exceeds 
node: 128 configured maximum of 128 

nodes. 

C2C_ | Neg. | path: “/” SH_C_DISKSPACE Pass | Data segment size exceeds 
node: 0 available clusters. 
size: 134217728 

C2D_ | Neg. | path: “a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C2E | Neg. | path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C2F | Neg. | path: “/0” SH_C_PATH_ERROR Pass __| Input “/0” is not a valid path. 




















Table 15. Test group 2: sh_c_make_dseg. 
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Test group 3: sh_c_make_subtree 













































































Test | Type Parameters Expected Result Pass? Remarks 

C3A.1 | Pos. | path: “/” No error, directory table created Pass 
node: 0 

C3A.2 | Neg. | path: “/” SH_C_NODE_ALREADY_EXISTS Pass | Duplicate directory table node 
node: 0 detected. 

C3B_ | Neg. | path: “/” SH_C_MAX_NODE_NAME Pass | Specified node name exceeds 
node: 128 configured max of 128 nodes. 

C3C_ | Neg. | path: “/” SH_C_DISKSPACE Pass | Available disk space consumed 
node: 0 prior to this test. 

C3D_ | Neg. | path: “a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C3E | Neg. | path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C3F_ | Neg. | path: “/0” SH_C_PATH_ERROR Pass __| Input “/0” is not a valid path. 








Table 16. 


Test group 3: sh_c_make subtree. 
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Test group 4: sh_c_open_dseg 















































Test | Type Parameters Expected Result Pass? Remarks 

C4A.1 | Pos. | path: “/” No error, handle zero returned. Pass_ | /1 was created prior to this test 
node: | 

C4A.2 | Pos. | path: “/” No error, handle one returned. Pass_ | /2 was created prior to this test 
node: 2 

C4A.3 | Neg. | path: “/” SH_C_HANDLE_TABLE_FULL Pass | All handles were consumed 
node: 3 prior to this test. 

C4B_ | Neg. | path: “/” SH_C_NO_SUCH_NODE Pass_ | No node exists at path “/10” 
node: 10 

C4C_ | Neg. | path: “a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C4D__| Neg. | path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C4E | Neg. | path: “/0” SH_C_PATH_ERROR Pass __| Path does not exist 























Table 17. 
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Test group 4: sh_c_open_dseg. 





Table 18 contains the results for test group 5, the sh_c_write_dseg interface. 
Two data segments of size 9,000 bytes were created and associated with handles. Two 
buffers, the first containing 9,000 bytes of pre-generated binary data, and the second 
containing 9,000 bytes of different pre-generated binary data, were created in the memory 
of the test system. Hashes were generated for each buffer, using the same technique used 
to generate the MAC for data segments in the storage hierarchy. The 
sh_c_write_dseg interface was then called on the first data segment handle to write 
the entirety of the first buffer to the data segment. The second data segment handle was 
written in two halves from the second 9,000 byte buffer. This tested the offset and byte 
count parameters that allow the interface caller to write the specified number of bytes at 


the specified byte offset in the data segment. 


Table 19 contains the results for test group 6, the sh_c_read_dseg interface. 
Tests C6A and C6B from this group are performed immediately after the corresponding 
tests CSA and CSB in test group 5. The contents of the two data segments that were 
previously written are read into buffers by the sh_c_read_dseg interface. New 
hashes are generated based on the contents of these buffers and compared to the hash 
values generated by the sh_c_write_dseg test group. By that showing these hash 
values are equivalent, the sh_c_read_dseg interface is shown to correctly read the 


contents of the correct data segments. 


Table 20 contains the results for test group 7, the sh_c_close_dseg interface. 
Test C7A uses the data segment opened and written from test CSA. When a data segment 
is closed, the hash value of its contents is generated and stored. The generated hash is 
compared to the hash value generated in test group 5 and found to be equivalent, 
demonstrating that sh_c_close_dseg correctly generates the hash of the data 


segment associated with the specified handle. 


Table 21 contains the results for test group 8, the sh_c_delete_dseg 
interface. A data segment at path ‘“/1” and a directory table at path “/2” were created for 


this test. The interface was tested by calling it to remove the data segment. 
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Test group 5: sh_c_write_dseg 






















































































Test | Type Parameters Expected Result Pass? Remarks 

C5A_ | Pos. | handle: 0 No error. Pass_ | All 9,000 bytes of buf_ptrl is 
buffer: buf_ptr1 written to the data segment 
byte count: 9000 
offset: 0 

C5B.1 | Pos. | handle: 1 No error. Pass | 4,500 bytes from buf_ptr2 is 
buffer: buf_ptr2 written to the beginning of the 
byte_count: 4500 data segment 
offset: 0 

C5B.2 | Pos. | handle: 1 No error. Pass | 4,500 bytes from buf_ptr2 is 
buffer: buf_ptr2 written to the data segment 
byte_count: 4500 beginning at byte offset 4,500. 
offset: 4500 

C5C | Neg. | handle: 2 SH_C_HANDLE_INVALID Pass | Bad handle passed as a 

parameter. 

C5D_ | Neg. | handle: 0 SH_C_DSEG_OFFSET_BOUND Pass_ | The supplied offset parameter is 
buffer: buf_ptr1 outside the bounds of the 9,000 
byte_count: 9000 byte data segment. 
offset: 9200 

CSE | Neg. | handle: 0 SH_C_INSUFFICENT_SPACE Pass | The specified byte count 8,000 
buffer: buf_ptr1 cannot be written within the 
byte count: 8000 bounds of 9,000 — 2,000 bytes. 
offset: 2000 

CSF | Neg. | handle: 0 SH_C_INPUT_BUFF_NULL Pass | Input buffer is null. 
buffer: NULL 

Table 18. Test group 5: sh_c_write_dseg. 
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Test group 6: sh_c_read_dseg 















































Test | Type Parameters Expected Result Pass? Remarks 

C6A_ | Pos. | handle: 0 No error. Pass | All 9,000 bytes of the data 
buffer: buf_ptr1 segment is read into buf_ptrl. 
byte_count: 9000 Performed after CSA. 
offset: 0 

C6B.1 | Pos. | handle: 1 No error. Pass | The first half of the data 
buffer: buf_ptr2 segment is read into buf_ptr2. 
byte count: 4500 Performed after C5B.1 
offset: 0 

C6B.2 | Pos. | handle: 1 No error. Pass | The second half of the data 
buffer: buf_ptr2 segment beginning at byte offset 
byte count: 4500 4,500 is read into buf ptr2. 
offset: 4500 Performed after C5B.2 

CoC | Neg. | handle: 2 SH_C_HANDLE_INVALID Pass | Bad handle passed as a 

parameter. 

C6D_ | Neg. | handle: 0 SH_C_OFFSET_BOUND_ERROR Pass_ | The supplied offset parameter is 
buffer: buf_ptr1 outside the bounds of the 9,000 
byte_count: 9000 byte data segment. 
offset: 9200 

C6E Neg. | handle: 0 SH_C_OUTPUT_BUFF_NULL Pass | Output buffer is null. 








buffer: NULL 














Table 19. Test group 6: sh_c_read_dseg. 
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Test group 7: sh_c_close_dseg 



































































































































Test Parameters Expected Result Pass? Remarks 

C7A.1 handle: 0 No error, hash value generated and stored Pass__| Performed after C5A. 

C7A.2 handle: 0 SH_C_HANDLE_INVALID Pass | Handle was already closed in 

test C7A.1. 
C7B handle: 2 SH_C_HANDLE_INVALID Pass_ | Bad handle passed. 
Table 20. Test group 7: sh_c_close_dseg. 
Test group 8: sh_c_delete_dseg 

Test Parameters Expected Result Pass? Remarks 

C8A.1 path: “/” No error, data segment deleted Pass_ | /1 dseg was created prior to this 
node: | test. 

C8A.2 path: “/” SH_C_NO_SUCH_NODE Pass | Data segment was already 
node: | deleted. 

C8B path: “/” SH_C_MAX_NODE_NAME Pass | Specified node name exceeds 
node: 128 configured maximum of 128 

nodes. 

C8C path: “/” SH_C_NO_SUCH_NODE Pass 
node: 0 

C8D path: “/” SH_C_NODE_NOT_DSEG Pass_ | /2 directory was created prior to 
node: 2 this test. 

C8E path: “a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C8F path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C8G path: “/0” SH_C_PATH_ERROR Pass __| Path does not exist 























Table 21. 
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Test group 8: sh_c_delete_dseg. 








Table 22 contains the results for test group 9, the sh_c_delete_subtree 
interface. A simple tree structure was constructed to test the interface’s ability to descend 
and remove data segment and directory table nodes from the specified parent node. Three 
directory table nodes with paths “/1”, ‘“/1/1”, and ‘“/1/2” were created along with two data 
segment nodes at paths “/1/1/1” and “/1/2/1”. 


Table 23 contains the results for test group 10, the sh_c_get_child interface. 
The tree structure constructed for test group 9 was also used for testing this interface’s 


functionality. 


Table 24 contains the results for test group 11, the sh_c_get_dseg_size 





interface. A data segment of size 9,000 bytes and path “/1” and a directory table node of 
path ‘/2” were created prior to testing. Table 25 contains the results fpr test group 12, the 
sh_c_get_dseg_hash interface. A data segment of size 9,000 bytes and path “/1” 





was created, opened, and written to with 9,000 bytes of pre-generated binary data. The 
hash of the data segment contents were calculated and stored in the test program. The 
data segment was then closed. A directory node of path “/2” was also created for negative 


testing purposes. The sh_c_get_dseg_hash interface was called and returned an 





equivalent hash, demonstrating the interface retrieved the correct hash value. 


Table 26 contains the results for test group 13, the sh_c_check_hash 
interface. A data segment of size 9,000 bytes and path “/1” was created, opened, and 
written to with 9,000 bytes of pre-generated binary data. The data segment was then 


closed. A directory node of path “/2” was also created for negative testing purposes. 
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Test group 9: sh_c_delete_subtree 



















































































Test | Type Parameters Expected Result Pass? Remarks 

C9A | Neg. | path: “/1/1” SH_C_NODE_NOT_DIRNODE Pass | The specified node was a data 
node: | segment. 

C9B.1 | Pos. | path: “/” No error, directory and child nodes deleted. | Pass | A hierarchy off of /1 was 
node: | created prior to this test. 

C9B.2 | Neg. | path: “/” SHC -NO_ SUCH NODE Pass | Directory table node was 
node: | already deleted. 

C9B.3 | Neg. | path: “/1” SH_C_PATH_ERROR Pass | This path no longer exists 
node: | because parent node was deleted 

in test C9A.1 

C9C_ | Neg. | path: “/” SH_C_MAX_NODE_NAME Pass | Node name exceeds configured 
node: 128 maximum of 128 nodes. 

C9D_ | Neg. | path: “/” SH_C_NO_SUCH_NODE Pass_ | No node exists at path “/0” 
node: 0 

C9E | Neg. | path: “a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C9F | Neg. | path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C9G_ | Neg. | path: “/0” SH_C_PATH_ERROR Pass __| Path does not exist 























Table 22. 


Test group 9: sh_c_ delete subtree. 
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Test group 10: sh_c_get_child 

























































































Test Type Parameters Expected Result Pass? Remarks 
C10A_ | Pos. | path: “/” No error, node name and directory node type | Pass 
node: | returned for node at path ‘/1/1” 
offset: 0 
C10B_ | Pos. | path: “/” No error, node name and directory node type | Pass 
node: | returned for node at path “/1/2” 
offset: 1 
C10C_ | Neg. | path: “/” SH_C_OFFSET_BOUND_ERROR Pass 
node: | 
offset: 2 
C10D_ | Pos. | path: “/1” No error, node name and data segment node | Pass 
node: | type returned for node at path ‘/1/1/1” 
offset: 0 
C1OE | Neg. | path: “/1/1” SH_C_NODE_NOT_DSEG Pass | The specified node is a data 
node: | segment. 
C10OF | Neg. | path: “/” SH_C_MAX_NODE_NAME Pass_ | Node name exceeds configured 
node: 128 maximum of 128 nodes. 
C10G_ | Neg. | path: “/” SH_C_NO_SUCH_NODE Pass_ | No node exists at path “/0” 
node: 0 
C10H_ | Neg. | path: “a” SH_C_MALFORMED_PATH Pass __| Input path is malformed. 
C101 Neg. | path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 
C10J Neg. | path: “/0” SH_C_PATH_ERROR Pass | Path does not exist 








Table 23. Test group 10: sh_c_get_child. 
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Test group 11: sh_c_get_dseg_size 

































































Test | Type Parameters Expected Result Pass? Remarks 

C11A | Pos. | path: “/” No error, data segment size returned Pass_ | /1 dseg created prior to this test. 
node: | 

C11B | Neg. | path: “/” SH_C_NODE_NOT_DSEG Pass | /2 was created as a directory 
node: 2 node prior to this test. 

C11C | Neg. | path: “/” SH_C_NO_SUCH_NODE Pass_ | No node exists at path “/3” 
node: 3 

C11D | Neg. | path: “/” SH_C_MAX_NODE_NAME Pass | Node name exceeds configured 
node: 128 maximum of 128 nodes. 

CIIE | Neg. | path: “a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C11F | Neg. | path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C11G | Neg. | path: “/0” SH_C_PATH_ERROR Pass __| Path does not exist 























Table 24. 


Test group 11: sh_c_ get dseg size. 
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Test group 12: sh_c_get_dseg_hash 

































































Test | Type Parameters Expected Result Pass? Remarks 

C12A | Pos. | path: “/” No error, data segment hash returned Pass_ | /1 dseg was created prior to this 
node: | test. 

C12B | Neg. | path: “/” SH_C_NODE_NOT_DSEG Pass | /2 was created as a directory 
node: 2 node prior to this test. 

C12C | Neg. | path: “/” SH_C_NO_SUCH_NODE Pass_ | No node exists at path “/3” 
node: 3 

C12D | Neg. | path: “/” SH_C_MAX_NODE_NAME Pass | Node name exceeds configured 
node: 128 maximum of 128 nodes. 

C12E | Neg. | path: “a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C12F | Neg. | path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C12G | Neg. | path: “/0” SH_C_PATH_ERROR Pass __| Path does not exist 























Table 25. 
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Test group 12: sh_c_ get dseg_ hash. 








Test group 13: sh_c_check_hash 










































































Test | Type Parameters Expected Result Pass? Remarks 

C13A | Pos. | path: “/” No error, true value returned Pass_ | /1 dseg was created prior to this 
node: | test 

C13B | Neg. | path: “/” SH_C_NODE_NOT_DSEG Pass | /2 was created as a directory 
node: 2 node prior to this test. 

C13C | Neg. | path: “/” SH_C_NO_SUCH_NODE Pass_ | No node exists at path “/3” 
node: 3 

C13D | Neg. | path: “/” SH_C_MAX_NODE_NAME Pass | Node name exceeds configured 
node: 128 maximum of 128 nodes. 

C13E | Neg. | path: “a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C13F | Neg. | path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

C13G | Neg. | path: “/0” SH_C_PATH_ERROR Pass | Path does not exist 








Table 26. 
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Test group 13: sh_c_check_hash. 





Ze Initialization Interface Testing 


Initialization interface testing is only fully informative if it occurs after data 
segment and directory nodes have already been created. All tests were performed after 


the test storage hierarchy was modified as described for each group. 


Table 27 contains the _ results for test group 1, ‘the 
sh_i_initialize_databases interface. Table 28 contains the results for test 
group 2, the sh_i_get_hand1e interface. The storage hierarchy was initialized with a 
handle table size of one row and two data segment of paths “/1” and “/2” were created 
prior to this test. A directory table node was also created at path ‘“/3”. Table 29 contains 
the results for test group 3, the sh_i_read_in interface. A data segment at size 9,000 
bytes and path “/1” was created, opened, and written to with 9,000 bytes of pre-generated 
data using configuration interfaces prior to this test. The interface was called and the 


expected data was loaded into a test program buffer. 


Table 30 contains the results for test group 4, the sh_i_get_dseg_size 





interface. A data segment of size 9,000 bytes and path “/1” was created prior to testing. 


Table 31 contains the results for test group 5, the sh_i_get_dseg_hash interface. A 





data segment of size 9,000 bytes and path “/1” was created, opened, and written to with 
9,000 bytes of pre-generated binary data using configuration interfaces. The hash of the 
data segment contents were calculated and stored in the test program. The data segment 
was then closed. A directory node at path ‘“/2” was also created for negative testing 


purposes. The sh_i_get_dseg_hash interface was called and returned the same hash 





value, demonstrating the interface retrieved the correct hash value. 
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Test group 1: sh_i_initialize databases 















































Test | Type Parameters Expected Result Pass? Remarks 

I1A | Pos. | block offset: 8 No error, database structures loaded. Pass_ | Offset 8 is the correct value 

IIB_ | Neg. | block_offset: 0 SH_C_CONFIG_DB LOAD ERR Pass 

114C | Neg. | block_offset: 8 SH_C_CLUS_DB_LOAD_ERR Pass | Configuration database altered to 
reflect incorrect location of cluster 
database. 

I1D | Neg. | block_offset: 8 SH_C_SAT_LOAD_ERR Pass | Configuration database altered to 

















reflect incorrect location of SAT 





Table 27. Test group 1: sh_i_initilizase_databases. 
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Test group 2: sh_i_get_handle 



















































































Test | Type Parameters Expected Result Pass? Remarks 

I2A.1 | Pos. | path: “/” No error, handle zero returned. Pass |/1 dseg was created prior to this 
node: | test. 

I2A.2 | Neg. | path: “/” SH_C_HANDLE_TABLE_FULL Pass | All handles were consumed 
node: 2 prior to this test. 

I2B Neg. | path: “/” SH_C_NODE_NOT_DSEG Pass | /3 directory node was created 
node: 3 prior to this test. 

I2C Neg. | path: “/” SH_C_NO_SUCH_NODE Pass_ | No node exists at path “/10” 
node: 10 

I2D Neg. | path: “/” SH_C_MAX_NODE_NAME Pass | Node name exceeds configured 
node: 128 maximum of 128 nodes. 

I2E Neg. | path: “a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

I2F Neg. | path: “/a” SH_C_MALFORMED_PATH Pass _| Input path is malformed. 

2G Neg. | path: “/0” SH_C_PATH_ERROR Pass __| Path does not exist 











Table 28. 
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Test group 2: sh_i_get_handle. 








Test group 3: sh_i_read_in 
































































































































Test | Type Parameters Expected Result Pass? Remarks 
I3A Pos. | handle: 0 No error, data read in from data segment. Pass | A valid handle was obtained 
buffer: buf_ptr1 prior to this test. 
I3B Neg. | handle: 1 SH_C_HANDLE_INVALID Pass__| Bad handle passed. 
Table 29. Test group 3: sh_i_read_in. 
Test group 4: sh_i_get_dseg_size 
Test | Type Parameters Expected Result Pass? Remarks 
I4A Pos. | handle: 0 No error, data segment size returned Pass | A valid handle was obtained 
prior to this test. 
I4B Neg. | handle: 1 SH_C_HANDLE_INVALID Pass__| Bad handle passed. 
Table 30. Test group 4: sh i get dseg size. 
Test group 5: sh_i_get_dseg_hash 
Test | Type Parameters Expected Result Pass? Remarks 
ISA Pos. | handle: 0 No error, data segment hash returned Pass | A valid handle was obtained 
prior to this test. 
I5B Neg. | handle: 1 SH_C_HANDLE_INVALID Pass__| Bad handle passed. 



































Table 31. Test group 5: sh_1 get dseg_ hash. 
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a: Runtime Interface Testing 


Storage hierarchy runtime interfaces must be called after the handle table database 
has been initialized and handles have been associated with data segments. Each runtime 
interface test group is performed after these interfaces have been called and one data 
segment with handle zero is has been retrieved by the sh_i_get_hand1e interface 
call. This data segment is of size 9,000 bytes and contains pre-generated binary data. The 


test program calculates and stores the hash value of this data for future comparison. 


Table 32 contains the results for test group 1, the sh_r_read_in interface. The 
interface is called using a handle value of 0 and stores the data read from the data 
segment in a test program memory buffer. Table 33 contains the results for test group 2, 
the sh_r_write_out interface, which is performed immediately after test group 1. 
The test program modifies the 9,000 byte buffer in memory, calculates the new hash 


value, and calls the interface to write the data back to the data segment. Table 34 contains 





the results for test group 3, the sh_r_get_dseg_hash interface. This test is 
performed immediately after test group 2, and returns the hash generated by the 
sh_r_write_out interface. This hash is compared with the hash generated by the test 
program in test group 2. By demonstrating that the two hashes are equal, both 


sh_r_write_out and sh_r_get_dseg_hash interfaces are shown to function 





correctly. The sh_r_write_out interface generates the correct hash value, which is 





returned by calling the sh_r_get_dseg_hash interface. 





Table 35 contains the results for test group 4, the sh_r_get_dseg_size 
interface. Table 36 contains the results for test group 5, the sh_r_check_hash 
interface. A data segment of size 9,000 bytes and path “/1” was created, opened, and 
written to with 9,000 bytes of pre-generated binary data. The data segment was then 


closed. 
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Test group 1: sh_r_read_in 






























































































































































Test | Type Parameters Expected Result Pass? Remarks 
RIA_ | Pos. | handle: 0 No error, data read in from data segment. Pass | A valid handle was obtained 
buffer: buf_ptr1 prior to this test. 
RIB_ | Neg. | handle: 1 SH_C_HANDLE_INVALID Pass__| Bad handle passed. 
Table 32. Test group 1: sh_r_read_in. 
Test group 2: sh_r_write_out 
Test | Type Parameters Expected Result Pass? Remarks 
R2A_ | Pos. | handle: 0 No error, data written to data segment and | Pass | A valid handle was obtained 
buffer: buf _ptrl | new hash is generated. prior to this test. 
R2B | Neg. | handle: 1 SH_C_HANDLE_INVALID Pass__| Bad handle passed. 
Table 33. Test group 2: sh_r_write_out. 
Test group 3: sh_r_get_dseg_hash 
Test | Type Parameters Expected Result Pass? Remarks 
R3A_ | Pos. | handle: 0 No error, data segment hash returned Pass | A valid handle was obtained 
prior to this test. 
R3B__| Neg. | handle: 1 SH_C_HANDLE_INVALID Pass__| Bad handle passed. 
Table 34. Test group 3: sh_r_get_dseg hash. 
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Test group 4: sh_r_get_dseg_size 







































































Test | Type Parameters Expected Result Pass? Remarks 

R4A_ | Pos. | handle: 0 No error, data segment size returned Pass | A valid handle was obtained 
prior to this test. 

R4B | Neg. | handle: 1 SH_C_HANDLE_INVALID Pass__| Bad handle passed. 

Table 35. Test group 4: sh_r get _dseg size. 
Test group 5: sh_r_check_hash 

Test | Type Parameters Expected Result Pass? Remarks 

RS5A_ | Pos. | handle: 0 No error, true value returned Pass | A valid handle was obtained 
prior to this test. 

RSB__| Neg. | handle: 1 SH_C_HANDLE_INVALID Pass__| Bad handle passed. 



































Table 36. Test group 5: sh_r_check_hash. 
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Cc. SUMMARY 


This chapter presented a storage hierarchy scenario and the results of tests 
performed on each external interface. The procedures for recreating these test results are 
contained in Appendix B. Chapter V discusses the results of this study, related work, and 


suggests future work to improve upon the results of this thesis. 
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V. RESULTS 


The storage hierarchy prototype developed in this thesis is a near-complete 
implementation of the LPSK product functional specification for secondary storage of 
data segments [15]. The design and development of the prototype has shown that 
requirements can be derived from this specification for secondary storage of data 
segments, leading to the design, implementation, and successful testing of a storage 
hierarchy prototype. The prototype presents interfaces that can be used to construct a 
storage hierarchy structure on storage media for which a hardware abstraction layer has 
been provided. The prototype contains modules that are used for off-line configuration 
and both LPSK initialization and runtime operation modes to access the contents of data 
segments. The prototype is capable of maintaining configuration and data segment 
permanence by saving its configuration databases to secondary storage and loading the 
configuration databases at some later time. This storage hierarchy prototype, however, is 
not suitable for inclusion in the LPSK binary due to several incomplete features and a 
prototype design choice. These issues are discussed in this chapter. The chapter starts 
with a discussion of several problems and challenges encountered in this study and 
continues with a presentation of incomplete features of the storage hierarchy prototype, 


related work, and suggestions for future work related to the LPSK storage hierarchy. 


A. PROBLEMS ENCOUNTERED 
1. Hardware Abstraction 


The first challenge encountered was the lack of LPSK disk device driver software. 
This driver software facilitates the reading and writing of data between programs and a 
particular secondary storage device, such as a hard disk drive. Without this software 
layer, many aspects of the storage hierarchy prototype that rely on storing and modifying 
configuration information could not be tested directly on the LPSK and shown to 
function correctly. The solution to this problem was to design a hardware abstraction 


layer to hide the complexity of reading and writing to disk from the storage hierarchy 
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interfaces. The linux dd command-line tool was used by a HAL developed in this thesis 
to read and write data to a virtual disk, as described in the implementation methodology 


found in Chapter III. 


Zz Memory Allocation 


Another challenge was the lack of the complete set of standard C library functions 
on the LPSK platform. Program developers rely on C libraries to perform oftentimes 
complex programming tasks quickly and easily, such as reserving primary memory or 
working with C strings. Implementation of functions that were necessary for storage 
hierarchy modules but had not been implemented for the LPSK added to the overall 
programming workload. This challenge led to an additional problem regarding memory 


allocation. 


The handle table and SAT databases vary in size based on the configuration of 
storage hierarchy. Primary memory is reserved for these databases dynamically during 
their initialization. In the context of the configuration interfaces, this can be accomplished 
by the C standard library call malloc, which returns a pointer to a primary memory data 
segment of the specified size. This library call interacts with the operating system’s 
memory manager to reserve this memory. A comparable library call does not exist in the 
LPSK platform. The LPSK memory model is also fundamentally dissimilar to the 
memory model of the Linux testing workstation. Because all aspects of the storage 
hierarchy were tested on a Linux platform, it was necessary to substitute portions of code 
that would have otherwise interacted with the LPSK memory manager with calls to the C 
standard library malloc Dynamic memory allocation was also avoided in situations 


where it might otherwise have led to more streamlined and elegant code. 


3. File System Analogy 


This study often relied on the similarities found in the functional specification for 
the secondary storage of LPSK data segments and the structure of contemporary file 
systems. The storage hierarchy organizes data segments in a tree-like hierarchal fashion. 


This is similar to the way file systems such as Microsoft Corporation’s FAT file system 


dd 


or the Linux “ext3” file system organize files in a hierarchal directory-tree structure. The 
contemporary file system analogy was attractive because of the way it framed the 
discussion of the requirements and design of the storage hierarchy prototype in context 
likely to be familiar to readers. This approach of treating the storage hierarchy like a 
specialized file system, however, influenced the design of the storage hierarchy prototype 
in such a way that the design was no longer congruent to the functional specification. It 
was assumed that an inner node—a node that has child nodes—could not also be a data 
segment. While the LPSK functional specification does not explicitly require that inner 
nodes may represent data segments, the assumption arrived at in the design of this storage 
hierarchy prototype does not allow such dual-purpose nodes. As a result, the storage 
hierarchy prototype developed in this thesis may not be said to be a complete or fully 
accurate LPSK storage hierarchy implementation, depending on the interpretation of the 
functional specification. Significant modification of the storage hierarchy prototytpe 


would be required to allow inner nodes to contain data.. 


B. INCOMPLETE FEATURES 


Several features of the LPSK storage hierarchy prototype are incomplete due to a 
lack of documented requirements or incomplete features of the LPSK itself. The 
prototype is not capable of making the LPSK system calls necessary to reserve 
dynamically-sized segments of primary memory. This functionality must be added to the 


prototype to make it capable of executing as part of the LPSK binary. 


Many initialization and runtime interfaces are required to cause the LPSK 
platform to halt on certain error cases. Comment lines are included in storage hierarchy 


module files indicating where the system calls to make the kernel halt are to be inserted. 


Another incomplete feature involves data segment MAC generation. The external 
interface specification developed in this thesis does not include parameters that allow the 
interface caller to supply the key used to generate a data segment MAC. Instead, the 
storage hierarchy prototype makes use of a SHA-256 hash implementation to generate a 


collision-free substitution MAC used for testing the storage hierarchy external interfaces. 
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The prototype can be modified to accept MAC keys through the external interfaces in 
both LPSK and non-LPSK contexts, or in the case of LPSK context interfaces, code can 


be added to access the primary memory location of the MAC key. 


Cc, RELATED WORK 
This section presents several related data and file storage systems. 


Security Enhanced Linux (SELinux) is a joint effort between the National 
Security Agency (NSA) and the Linux community to implement a variety of mandatory 
access control policies for the Linux operating system [19]. It associates security labels 
with file system objects and users, and mediates access to files in the Linux file system 
based on SELinux security policies. SELinux policies separate information based on 
confidentiality and integrity labels. SELinux components must be built into and compiled 
with the Linux kernel in order to enforce its policies. Since SELinux functionality is 
bolted on to the Linux kernel, which is not a high assurance operating system, it does not 


meet the high assurance objectives of the LPSK. 


The XTS-400 Trusted Computer System is a commercial high assurance 
computing platform combining evaluated hardware and the STOP operating system [20]. 
XTS-400 systems host and separate users and information of various sensitivity levels 
and stores data in a hierarchical file system. It has been successfully evaluated at EAL5+ 


[21] 


The Gemini Trusted Network Processor (GTNP), a product of Gemini Computers, 
Inc., implements a specialized storage mechanism for the secondary storage of its data 
segments [22]. A GTNP data segment is a variable sized unit of storage that can be 
swapped in and out of primary memory to some secondary store by a segment storage 
system. All GITNP processes to which a GTNP data segment has made known modify the 
same segment in primary memory. Neither the STOP OS nor the GTNP are separation 
kernels and reflect an architectural approach different than that of the LPSK. 
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Like the LPSK, GITNP data segments are logically organized in a hieratical 
fashion. Every node of the hierarchy can simultaneously contain data and have a number 
of child nodes. Data segments are made known to processes by exporting a path to a 
subtree. If there is a hierarchy of GINP data segments labeled 5-6-9-10, for example, and 
the path 5-6 is exported to a process, then data segments 9 and 10 have been made known 


to the process. The process is unaware of any data segments above this subtree. 


D. FUTURE WORK 


This section presents suggestions for future work that can be used to improve the 


storage hierarchy prototype developed in this thesis. 


i Fs Performance and Optimization 


The main factor influencing the performance of the storage hierarchy external 
interfaces, in terms of execution time, is storage medium access. Interfaces access to the 
storage medium through the HAL. Every interface accesses the storage medium to some 
varying degree, with some interfaces performing ten or more discrete disk access events. 
As interfaces traverse the tree structure of particularly deep storage hierarchy trees, the 
number of discrete accesses can rapidly increase. One optimization that could be 
employed to reduce the amount of execution time spent waiting for disk accesses to 


complete is to cache the commonly accessed disk sectors. 


Directory table clusters are read from the storage medium by any interface that 
takes a storage hierarchy path as a parameter. These directory tables are loaded into 
memory and are searched for the SAT index of the next directory table of the path, which 
is then loaded into memory, until the entire path has been traversed by this cycle of 
directory table reference. The principle of temporal locality [23] suggests that if a 
directory table has been recently accessed, it will be accessed again in the near future. 
During configuration, for example, after the interface call has been made to create a 
directory table at a given path, it is likely that future interface calls will use the same path 
to populate the newly created directory table with child data segment and directory table 


nodes. A directory table caching module would reduce the execution time of many 


fe 


interfaces by caching directory table structures in memory and intercepting calls to the 


HAL to load a directory table if it already exists in the cache. 


Each storage hierarchy configuration interface acts as an atomic operation. Any 
modifications that are made to the SAT, directory tables, or cluster database are 
immediately committed to the storage medium by the HAL. While this behavior has 
positive attributes—a storage hierarchy remains in a valid state if a configuration tool 
unexpectedly ends execution—it also has some negative performance attributes in that 
the storage medium is accessed often. A configuration interface and supporting module 
could be added to the prototype that only commits the modified databases to the storage 
medium after the configuration tool user has decided to end a configuration session. This 


feature would reduce the amount of storage medium access during configuration. 


2. Formatting Tool 


A storage hierarchy’s storage medium must be formatted with information about 
the configuration and dimensions of the storage hierarchy before configuration interfaces 
may be used. This was accomplished during testing of the storage hierarchy external 
interfaces by a C program that created and populated the basic storage hierarchy 
structures in memory and then invoked the HAL to commit these structures to the disk. 
Chapter IV contains a description of how this was accomplished by the test program. The 
test program, however, relied on hard-coded values when formatting the storage medium. 
Configuration interfaces could be added to the storage hierarchy prototype that would 


allow a configuration tool to format a storage medium using the parameters it specifies. 


E. CONCLUSION 


The storage hierarchy prototype was designed and implemented to meet the 
requirements derived from the LPSK product functional specification for the secondary 
storage of data segments. While the prototype is not a wholly accurate implementation, 
its development has increased the attention paid to this aspect of the LPSK and has 
generated documentation and C code that can be used to further the goals of the TCX 
project. This study began with the analysis of the LPSK functional specifications and 


continued with the creation of an external interface specification document which 
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demarcated the boundary between the storage hierarchy and the rest of the LPSK (see 
Appendix A). Development began after internal databases and modules of the storage 
hierarchy had been identified. Development was followed by a series of tests and 
prototype corrections to confirm the positive and negative behaviors of the external 


interfaces conformed to the external interface specification. 
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APPENDIX A: LPSK STORAGE HIEARCHY INTERFACES 


This appendix outlines the external interfaces of the storage hierarchy. Interfaces 
are groups of configuration, initialization, and runtime functions and are detailed in 
separate sections. Constants referenced in the following sections are defined in the 
respective header files of each function group. Functions return a success code 


NO_ERROR if the function call is successful. 


For the purposes of Appendix A, primitive variables referred to as int (integer) are 


of 32-bit length. 
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A. CONFIGURATION INTERFACE 


This section describes the functions used to configure the storage hierarchy 


executing in a non-LPSK context. The functions are implemented and executed on a 


system that has access to the C programming language standard libraries, including 


standard input/output. The functions are exposed to a configuration tool as a series of 


function calls. They are: 


sh_c_initialize_ databases 
sh_c make dseg 
sh_c_make_ subtree 
sh_c open dseg 
sh_c write dseg 
sh_c close _dseg 
sh_c delete _dseg 
sh_c_delete_subtree 
sh_c_ get child 

sh_c get dseg size 
sh_c get _dseg hash 
sh_c_read_dseg 


sh_c_ check hash 


The following subsection details these functions. 
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sh_c_initialize_databases 
This function reads the storage hierarchy configuration from disk into memory. 


1.1 Prototype 
unsigned int sh_c_initialize_databases 
const unsigned int offset); 


1.2 Inputs 
e offset 
The disk block offset into the storage medium where the storage 
hierarchy configuration data is located. 


1.3 Outputs 
e Function Result 
A numerical value that indicates success or failure of the function. 


1.4 Processing 

1. Attempt to load the configuration database into memory from disk at 
input offset. If a configuration database is not found, return 
SH_C_CONFIG_ DB LOAD ERR error. If memory can not be 
allocated, return SH_C_ MEM ALLOC_ERR error. 

2. Attempt to load the cluster database into memory from disk. Ifa 
cluster database is not found, return SH C CLUS DB LOAD ERR 
error. If memory can not be allocated, return 
SH_C_MEM_ ALLOC ERR error. 

3. Attempt to load the SAT into memory from disk. If a SAT structure is 
not found, return SH_C_ SAT LOAD ERR. If memory can not be 
allocated, return SH_C_ MEM ALLOC_ERR error. 

4. Construct the handle to data segment table in memory. 

5. Return NO_ERROR. 





1.5 Effects 
e This function reduces the available primary memory to 
accommodate the databases. 
e 
1.6 Errors 


SH_C CONFIG DB LOAD ERR 


This error is returned if the data loaded from disk does not 
represent a configuration database structure. 
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SH_C_CLUS_ DB LOAD ERR 


This error is returned if the data loaded from disk does not 
represent a cluster database structure. 


SH_C_SAT_LOAD ERR 


This error is returned if the data loaded from disk does not 
represent a SAT structure. 


SH_C MEM ALLOC ERR 


This error is returned if a memory allocation library call fails to 
return a valid buffer pointer. 
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sh_c_make_dseg 


This function creates a child node in the storage hierarchy and designates it as a 
data segment node. 


2.1 Prototype 
unsigned int sh_c_make_dseg( 
const char * const path 
const unsigned int node 
const unsigned int size); 


2.2 Inputs 


path 

The absolute path in the storage hierarchy of the parent of the new 
child node. The string is null-terminated and cannot exceed 
MAX PATH LENGTH bytes in length (including the null 
terminator). 

node 

The name of the new data segment node. 

size 

Defines the size of the data segment in bytes. 


2.3 Outputs 


Function Result — ; ; 
A numerical value that indicates success or failure of the function. 


2.4 Processing 


1. 


Verify that there exists enough free disk space to create a data segment 
of the specified input size. If the space does not exist, then return 
SH_C_DISKSPACE error. 


. Validate the input path as a correctly formed path string. Return 


SH_C_ MALFORMED PATH error if validation fails. The path shall 
only consist of the following characters: /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 
NULL. 

Attempt to walk the storage hierarchy along the specified input path. 
Return SH_C_PATH_ERROR error if the path specified by the input 
path does not exist in the storage hierarchy. 

Verify that the specified child node to be created does not already 
exist. If it does, return the SH C_ NODE ALREADY EXISTS error. 
Verify that the addition of this child would not exceed the configured 
maximum child limit. Return SH_C_CHILD_LIMIT_ REACHED 
error of it does. 

Instantiate the data segment node by updating the parent node’s node 
table structure, reserve required storage memory, initialize the storage 
memory to 0x0. 
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7. Calculate the message authenticate code for the segment and store the 


hash in the parent node’s table structure. 


8. Return NO_ERROR. 


2.5 Effects 


2.6 Errors 


The node directory table of the new data segment node’s parent node 
is updated to reflect the creation of the new data segment node. 
Space necessary to store the data segment is reserved by updating the 
internal data structures of the storage hierarchy. 

The data segment node entry in the directory table structure is 
modified, with the data segment length field set to the specified input 
size and the hash field set to the calculated hash. 

The data segment is initialized to 0x0 in every byte. 


SH_C_DISKSPACE 


This error is returned if there is not enough free disk space to 
create a data segment of the input size. 


SH_C MALFORMED PATH 


This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
oo) 


SH_C PATH ERROR 


This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 


SH_C NODE ALREADY EXISTS 


This error is returned if the node specified by the input path and 
node already exists. 


SH_C_CHILD LIMIT REACHED 


This error is returned if creating a new child node would exceed 
the configured maximum child count at the level specified by input 
path. 
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sh_c_make_subtree 


This function creates a child node in the storage hierarchy and designates it as a 
directory node. 


3.1 Prototype 
unsigned int sh_c_make_subtree( 
const char * const path 
const unsigned int node); 


3.2 Inputs 


path 

The absolute path in the storage hierarchy to the parent of a new child 
node. The string is null-terminated and cannot exceed 
MAX PATH LENGTH bytes in length. 

node 

The name of the new directory node. 


3.3 Outputs 


Function Result at ; ; 
A numerical value that indicates success or failure of the function on 


the specified path. 


3.4 Processing 


1. 


2 


Nn 


Verify that there exists enough free disk space to create a directory 
node If the space does not exist, then return SH_C_DISKSPACE error. 
Validate the input path as a correctly formed path string. Return 
SH_C_ MALFORMED PATH error if validation fails. The path shall 
only consist of the following characters: /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 
NULL. 

Attempt to walk the storage hierarchy along the specified input path. 
Return SH_C_PATH_ERROR error if the path specified by the input 
path does not exist in the storage hierarchy. 

Verify that the specified child node to be created does not already 
exist. If it does, return the SH C_NODE ALREADY EXISTS error. 
Allocate disk space for the node and initialize it to 0x0. 

Instantiate the directory node by updating the parent node’s node 
directory structure 

Return NO ERROR. 
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3.5 Effects 
e The node directory table of the new directory node’s parent node is 
updated to reflect the creation of the new directory node. 
e Anew directory table structure is created in a free data block for the 
new directory node’s table structure. 
e The amount of available disk space is reduced 
3.6 Errors 
SH_C_DISKSPACE 


This error is returned if there is not enough free disk space to 
create a directory node. 


SH_C MALFORMED PATH 


This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
he 

SH_C_PATH ERROR 
This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 

SH_C_NODE ALREADY EXISTS 
This error is returned if the node specified by the input path 
already exists. 
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4. sh_c_open_dseg 


This function returns a handle associated with the specified data segment and 
allows it to be written to and read from. 


4.1 Prototype 
unsigned int sh_open_dseg( 
const char * const path 
const unsigned int node 
const unsigned int * handle); 


4.2 Inputs 
e path 
The absolute path in the storage hierarchy to the parent of a data 
segment node. The string is null-terminated and cannot exceed 
MAX PATH LENGTH bytes in length. 
e node 
The name of the data segment node. 


4.3 Outputs 


e Handle : 
A handle to the associated data segment. 


e Function Result ae ; : 
A numerical value that indicates success or failure of the function. 


4.4 Processing 

1. Verify that there is an available handle to return. Return 
SH_C_ HANDLE TABLE FULL if no handle is available. 

2. Validate the input path as a correctly formed path string. Return 
SH_C_ MALFORMED PATH error if validation fails. The path shall 
only consist of the following characters: /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 
NULL. 

3. Attempt to walk the storage hierarchy along the input path. Return 
SH_C_PATH_ERROR error if the path specified by the input path 
does not exist in the storage hierarchy. 

4. Verify that there exists a child at the input node off the parent. If no 
such child node exists, return SH C NO SUCH NODE. 

5. Verify that the specified child node is a data segment node. If it is a 
directory node, return SH C NODE NOT_DSEG error. 

6. Verify that the specified data segment is not already in an open state. 
Return SH_C_DSEG_ARLEADY_ OPEN error if the segment is 
already open. 

7. Associate a handle with the data segment and return the handle. 

8. Return NO ERROR. 

4.5 Effects 
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e The configuration interface open data segment database is modified to 
associate the generated handle value with the specified data segment. 
The data segment is designated as being in an ‘open’ state. 


4.6 Errors 

SH_C_ HANDLE TABLE FULL 
This error is returned if too many segments are already open and 
no handles are available. 

SH_C_ MALFORMED PATH 
This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
cy 

SH_C_PATH_ ERROR 
This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 

SH_C_NO_SUCH_NODE 
This error is returned if the combination of input path and node 
does not exist. 

SH_C_NODE_ NOT _DSEG 
This error is returned if the node specified by the input path is not 
designated as a data segment node. 

SH_C_DSEG_ ALREADY OPEN 


This error is returned if the specified data segment is already open. 
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Di 


sh_c_write_dseg 


This function writes data from the specified buffer to the specified data segment 
starting at the offset provided. 


5.1 Prototype 
unsigned int sh_c_write_dseg( 


5.2 Inputs 


const unsigned int handle 
const void * const buffer 
const unsigned int byte_count 
const unsigned int offset 
unsigned int * bytes_written); 


handle 

The handle to the data segment to be written to. 

buffer 

The buffer from which the data is read. 

byte_count 

The number of bytes to write into the data segment. 

offset 

The offset into the data segment where writing is to begin. 


5.3 Outputs 


HE ke Wal SGmber of bytes written to the data segment. 


nction.Resul oe : . 
Unatnonioat vatae that indicates success or failure of the function. 


5.4 Processing 


1. 
2) 


Ee 


Ti 


5.5 Effects 


Set output bytes written to zero. 

Validate the input handle is associated with an open segment. Return 
SH_C_HANDLE INVALID if it is not 

Verify that the specified offset is within the bounds of the specified 
data segment. Return SH _C_ OFFSET BOUND _ ERROR error if it is 
not. 

Verify that the input buffer is not NULL. Return 
SH_C_INPUT_BUFF_ NULL if it is null. 

Verify that the specified number of bytes to read from the buffer can 
be accommodated by the data segment from the specified offset. 
Return SH_C_INSUFFICENT_SPACE error if it cannot. 

Attempt to write the specified number of bytes from the specified 
buffer. Set the output bytes written to the number of bytes successfully 
written. 

Return NO_ ERROR. 
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e Disk sectors are modified. If a close operation is not performed before 
the system halts, then the segment will be in a corrupted state because 
the stored hash will not correspond to the contents of the segment. 

e Ifthe input buffer is an invalid pointer, the behavior of the program is 
undefined, and will probably lead to a termination of the program by 
the operating systems. 


5.6 Errors 

SH_C_HANDLE INVALD 
This error if the specified handle is not a valid handle because it 
does not exist in the open data segment database. 

SH_C_OFFSET_ BOUND_ERROR 
This error is returned if the specified input offset is outside the 
bounds of the data segment. 

SH_C_INPUT_ BUFF NULL 
This error is returned if the specified input buffer pointer is NULL. 

SH_C_INSUFFICENT_ SPACE 
This error is returned if writing the amount of bytes specified by 
input length into the specified data segment beginning at the 
specified input offset would cause data to be written beyond the 
edge of the data segment. 
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6. 


sh_c_close_dseg 


This function closes the data segment associated with the supplied handle and 
calculates and stores the hash value for the segment. 


6.1 Prototype 
unsigned int sh_close_dseg(const unsigned int handle); 


6.2 Inputs 
e handle 
The handle of a data segment to be closed. 


6.3 Outputs 
e Function Result 
A numerical value that indicates success or failure of the function. 


6.4 Processing 

1. Validate the input handle is associated with a data segment. Return 
SH_C_HANDLE INVALID error if it is not. 

2. Calculate the hash value of the data stored in the data segment 
associated with the input handle and update the meta-data for the 
segment in the parent directory node. 

3. Remove the entry associated with the specified handle from the open 
data segment database node. 

4. Return NO ERROR. 


6.5 Effects 
e The hash value stored in the meta-data associated with the data 
segment is updated to reflect its (potentially) new contents. The handle 
is removed from the open data segment database and the data segment 
may no longer be written to or read from until it is opened again. 


6.6 Errors 
SH_C HANDLE INVALD 
This error if the specified handle is not a valid handle because it 
does not exist in the open data segment database. 
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7. sh_c_delete_dseg 


This function removes a data segment node from the storage hierarchy and frees 
its associated data blocks. 


7.1 Prototype 
unsigned int sh_c_ delete _dseg( 
const char * const path 
const unsigned int node); 


7.2 Inputs 
e path 
The absolute path in the storage hierarchy to the parent of the data 
segment to be deleted. The string is null-terminated and cannot exceed 
MAX PATH LENGTH bytes in length. 
e node 
The name of the node to be deleted. 


7.3 Outputs 
e Function Result 
A numerical value that indicates success or failure of the function. 


7.4 Processing 

1. Validate the input path as a correctly formed path string. Return 
SH_C_ MALFORMED PATH error if validation fails. The path shall 
only consist of the following characters: /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 
NULL. 

2. Attempt to walk the storage hierarchy along the specified input path. 
Return SH_C_PATH_ERROR error if the path specified by the input 
path does not exist in the storage hierarchy. 

3. Verify that a data segment record exists for the input node and path. 
Return SH_C_NO SUCH_NODE if it does not. 

4. Verify that the specified child node is a data segment node. If it is a 
directory node, return SH C NODE NOT_DSEG error. 

5. Remove the data segment node’s meta-data from the storage hierarchy 
and free the storage memory associated with the deleted node. 

6. Return NO_ERROR. 








7.5 Effects 
e The parent of the deleted node is updated to reflect the removal of the 
data segment node. 
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e Storage hierarchy internal data structures are modified so that storage 
memory allocated to the data segment are freed and available for 
future allocation. 

7.6 Errors 
SH_C_ MALFORMED PATH 
This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
cy 

SH_C_PATH_ ERROR 

This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 

SH_C_NO_SUCH_NODE 

This error is returned if the combination of input path and node 
does not exist. 

SH_C_ NODE NOT _DSEG 

This error is returned if the node specified by the input path is not 
designated as a data segment node. 
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8. sh_c_delete_subtree 


This function removes the specified directory node and all of its children nodes 
from the storage hierarchy. 


8.1 Prototype 
unsigned int sh_c_delete_subtree( 
const char * const path 
const unsigned int node); 


8.2 Inputs 
e path 
The absolute path in the storage hierarchy to the parent of the directory 
node to be removed. The string is null-terminated and cannot exceed 
MAX PATH LENGTH bytes in length. 
e node 
The name of the directory table node. 


8.3 Outputs 
e Function Result 
A numerical value that indicates success or failure of the function. 


8.4 Processing 

1. Validate the input path as a correctly formed path string. Return 
SH_C_ MALFORMED PATH error if validation fails. The path shall 
only consist of the following characters: /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 
NULL 

2. Attempt to walk the storage hierarchy along the specified input path. 
Return SH_C_PATH_ERROR error if the path specified by the input 
path does not exist in the storage hierarchy or only consists of ‘/’. 

3. Verify that a directory table record exists for the input node and path. 
Return SH_C_NO_ SUCH_NODE if it does not 

4. Verify that the specified node is a directory node. If it is a data 
segment node, return SH_C_NODE NOT _DNODE error. 

5. For all child data segment nodes, call sh_c_delete_dseg. For all 
child directory nodes, call this function (recursive). 

6. Remove the meta-data of the input node from the directory table 
associated with the input path. 

7. Mark the storage memory associated directory the node as available. 

8. Return NO ERROR. 
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8.5 Effects 
e The node directory table associated with the input path is updated to 
reflect the removal of the input node. 
e Storage hierarchy internal data structures are modified so that storage 
memory allocated to the directory node and all of its children nodes 
are freed and available for future allocation. 


8.6 Errors 

SH_C_ MALFORMED PATH 
This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
cy 

SH_C_PATH_ ERROR 
This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 

SH_C_NO_SUCH_NODE 
This error is returned if the combination of input path and node 
does not exist. 

SH_C_NODE_ NOT DNODE 
This error is returned if the node specified by the input path is not 
designated as a directory node. 
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oe 


sh_c_get_child 


This function returns a child nodes’ name and node type (data segment or 
directory) at the specified offset from the specified path in the storage hierarchy. 
This function provides a mechanism for “listing the contents” of a directory node. 


9.1 Prototype 
unsigned int sh_c_get child( 


9.2 Inputs 


const char * path 

const unsigned int node 

const unsigned int child_ offset 
unsigned int * name 

char * type); 


path 

The absolute path in the storage hierarchy to the parent of the directory 
node to be enumerated. The string is null-terminated and cannot 
exceed MAX PATH LENGTH bytes in length. 

node 

The name of the directory node. 

offset 

The offset into the list of children of the input parent node. 


9.3 Outputs 


name 
The name of the node at the specified offset as an unsigned int value. 
type 

The type of the node at the specified offset, where 
NODE_TYPE DSEG denotes a data segment node and 
NODE_TYPE_DIRT denotes a directory node. 

Function Result 

A numerical value that indicates success or failure of the function. 


9.4 Processing 


1. 


Validate the input path as a correctly formed path string. Return 
SH_C_MALFORMED PATH error if validation fails. The path shall 
only consist of the following characters: /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 
NULL. 


. Attempt to walk the storage hierarchy along the specified input path. 


Return SH_C_PATH_ERROR error if the path specified by the input 
path does not exist in the storage hierarchy. 
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7. 


9.5 Effects 


9.6 Errors 


. Verify that a data segment record exists for the input node and path. 


Return SH_C_NO_SUCH_NODE if it does not 
Verify that the input path and node specifies a directory node. If it is a 
data segment node, return SH_C_NODE_ NOT DNODE error. 





. Verify that input offset is not out of bounds of the list of children. 


Return SH_C_OFFSET BOUND ERROR if it is out of bounds. 
Return the child node name and type. 
Return NO_ERROR. 


This function has no effects. 


SH_C MALFORMED PATH 


This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
se) 2? 


SH_C PATH ERROR 


This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 


SH_C_NO_SUCH_ NODE 





This error is returned if the combination of input path and node 
does not exist. 


SH_C_NODE NOT _DNODE 





This error is returned if the node specified by the input path is not 
designated as a directory node. 


SH_C OFFSET BOUND ERROR 


This error is returned if the specified offset is not within the list of 
children. 
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Ors 


sh_c_get_dseg_size 





This function returns the length of the specified data segment in bytes. 


10.1 


Prototype 


unsigned int sh_c_get_dseg_ size( 


10.2 


10.3 


10.4 


10.5 


10.6 


const char * const path 
const unsigned int node 
const unsigned int * size); 


Inputs 

e path 
The absolute path in the storage hierarchy to new child node. The 
string is null-terminated and cannot exceed MAX PATH LENGTH 
bytes in length. 

e node 
The name of the node to retrieve the size for. 


Outputs 


: THe size of the data segment in bytes. 


: unction Result ie that indicates success or failure of the function. 


Processing 

1. Validate the input path as a correctly formed path string. Return 
SH_C_ MALFORMED PATH error if validation fails. The path shall 
only consist of the following characters: /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 
NULL. 

2. Attempt to walk the storage hierarchy along the specified input path. 
Return SH_C_PATH_ERROR error if the path specified by the input 
path does not exist in the storage hierarchy. 

3. Verify that a data segment record exists for the input node and path. 
Return SH_C_NO_SUCH_NODE if it does not 

4. Verify that the specified child node is a data segment node. If it is a 
directory node, return SH C NODE NOT_DSEG error. 

5. Consult the directory node table of the child node’s parent node and 
return the size in bytes for the data segment it reports. 

6. Return NO_ERROR. 








Effects 

e This function has no effects. 
Errors 

SH_C MALFORMED PATH 
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This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
cy 9 

SH_C_PATH_ ERROR 
This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 

SH_C_NO_SUCH_NODE 
This error is returned if the combination of input path and node 
does not exist. 

SH_C_NODE_ NOT _DSEG 
This error is returned if the node specified by the input path is not 
designated as a data segment node. 
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Le sh_c_get_dseg_hash 





This function returns the hash value of the specified data segment. 


11.1 Prototype 
unsigned int sh_c_get dseg_hash( 


const char * const const path 
const unsigned int node 
const void * const buffer); 


11.2 Inputs 


path 

The absolute path in the storage hierarchy to the data segment node. 
The string is null-terminated and cannot exceed 
MAX PATH LENGTH bytes in length. 

node 

The name of the node to retrieve the stored hash for. 


11.3 Outputs 


buffer 

The 256-bit buffer where the hash value of the data segment will be 
placed. 

Function Result 

A numerical value that indicates success or failure of the function. 


11.4 Processing 


1. 


2) 


Verify that the output buffer pointer is not null. Return 

SH_C_ BUFF PTR NULL if it is. 

Validate the input path as a correctly formed path string. Return 
SH_C_MALFORMED PATH error if validation fails. The path shall 
only consist of the following characters: /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 
NULL. 





. Attempt to walk the storage hierarchy along the specified input path. 


Return SH_C_PATH_ERROR error if the path specified by the input 
path does not exist in the storage hierarchy. 

Verify that a data segment record exists for the input node and path. 
Return SH_C_NO_SUCH_NODE if it does not 





. Verify that the specified child node is a data segment node. If it is a 


directory node, return SH_C_ NODE _NOT_DSEG error. 

Return the hash value stored in meta-data associated with the specified 
data segment. 

Return NO_ERROR. 
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11.5 Effects 
e Ifthe output buffer is an invalid pointer, then the behavior of the 
program is undefined, and will probably lead to termination of the 
program by the operating system. 


11.6 Errors 

SH_C_BUFF PTR NULL 
This error is returned if the input buffer is NULL. 

SH_C_ MALFORMED PATH 
This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
cy 

SH_C_PATH_ ERROR 
This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 

SH_C_NO_SUCH_NODE 
This error is returned if the combination of input path and node 
does not exist. 

SH_C_NODE_ NOT _DSEG 
This error is returned if the node specified by the input path is not 
designated as a data segment node. 








101 


2: sh_c_read_dseg 


This function reads the specified number of bytes starting at the offset provided 
from the data segment associated with the specified handle and writes it into the 
specified buffer. 


12.1 Prototype 
unsigned int sh_c_read_dseg( 
const unsigned int handle 
const void * const buffer 
const unsigned int byte count 
const unsigned int offset 
unsigned int * bytes_read); 
12.2 Inputs 
e handle 
The handle to a data segment to be read. 
e byte count 
The number of bytes to read from the data segment. 
e offset 
The offset into the data segment to begin reading data. 


12.3 Outputs 

e bytes read 
The number of bytes actually read from the specified data segment and 
placed into the input buffer. 

e buffer 
The pointer to the buffer to which data will be written. 

e Function Result 
A numerical value that indicates success or failure of the function. 


12.4 Processing 

1. Set the output bytes read to zero. 

2. Validate the input handle is associated with an open segment. Return 
SH_C_HANDLE INVALID if it is not 

3. Validate that the buffer is not null. Return 
SH_C_OUTPUT_ BUFF NULL if the pointer is null. 

4. Verify that the specified offset is within the bounds of the specified 
data segment. Return SH_C_ OFFSET BOUND _ ERROR error if it is 
not. 

5. Read the contents of the specified data segment at the specified offset, 

writing into the specified buffer. 
Return the number of bytes read from the data segment. 
7. Return NO_ERROR. 


aN 
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12.5 Effects 
e Ifthe input buffer is an invalid pointer, then the behavior of the 
program is undefined, and will probably lead to termination of the 
program by the operating system. 
12.6 Errors 
SH_C_HANDLE INVALD 
This error if the specified handle is not a valid handle because it 
does not exist in the open data segment database 
SH_C_OFFSET_BOUND_ERROR 
This error is returned if the specified input offset is outside the 
bounds of the data segment. 
SH_C_ OUTPUT_BUFF_ NULL 
This error is returned if the specified buffer cannot be written to. 
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13. sh_c_check_hash 


This function calculates the hash of the contents of the specified data segment and 
compares it with the hash stored in meta-data. 


13.1 Prototype 
unsigned int sh_c_check_hash( 
const char * const path 
const unsigned int node 
unsigned int * result); 


13.2 Inputs 
e path 
The absolute path in the storage hierarchy to a data segment node. The 
string is null-terminated and cannot exceed MAX PATH LENGTH 
bytes in length. 
e node 
The name of the data segment node. 


13.3 Outputs 
e result 
A value indicating the result of the hash comparison. 
e Function Result 
A numerical value that indicates success or failure of the function. 


13.4 Processing 


1. Validate the input path as a correctly formed path string. Return 
SH_C_MALFORMED PATH error if validation fails. The path shall 
only consist of the following characters: /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 
NULL. 

2. Attempt to walk the storage hierarchy along the specified input path. 
Return SH_C_PATH_ERROR error if the path specified by the input 
path does not exist in the storage hierarchy. 

3. Verify that a data segment record exists for the input node and path. 
Return SH_C_NO_ SUCH_NODE if it does not 

4. Verify that the specified child node is a data segment node. If it is a 
directory node, return SH C NODE NOT_DSEG error. 

5. Calculate the hash of the contents of the data segment and compare the 
result with the hash stored in the meta-data associated with the data 
segment. 

6. Set the output result to HASH EQUAL if the hash calculated is the 
same as the hash stored, op HASH NOT EQUAL if the hashes are not 
equal. 

7. Return NO_ERROR. 
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13.6 


Effects 
e This function has no effects. 


Errors 

SH_C_MALFORMED PATH 
This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
ed 

SH_C_PATH_ ERROR 


This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 

SH_C_NO_SUCH_NODE 
This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 

SH_C_NODE_ NOT _DSEG 
This error is returned if the node specified by the input path is not 
designated as a data segment node. 
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B. INITIALIZATION INTERFACE 


This section describes the functions used by the LPSK during system start up and 
initialization. The functions are exposed to the LPSK as a series of function calls. They 


are: 
e sh _i initialize databases 
e sh_i get handle 
e shi read _in 
e sh i get dseg size 
e shi get dseg hash 


The following subsection details these functions. 


106 


as 


sh_i_initialize databases 


This function reads the storage hierarchy configuration databases from disk in 
memory. 


1.1 Prototype 
unsigned int sh_i initialize_databases ( 
const unsigned int offset 
const unsigned int num_dsegs); 


1.2 Inputs 
e offset 
The disk block offset into the storage medium where the storage 
hierarchy configuration data is located. 
e num dsegs 
The number of handles that will be associated with data segments. 


1.3 Outputs 
e Function Result 
A numerical value that indicates success or failure of the function. 


1.4 Processing 

1. Attempt to read the configuration database from disk at input offset 
into memory. If a configuration database was not found, return 
SH_C_CONFIG_ DB LOAD ERR error. If there is not enough 
primary memory, cause the kernel to halt. 

2. Attempt to read the SAT from disk into memory. If a SAT structure 
was not found, return SH_C_SAT_LOAD ERR. If there is not enough 
primary memory, cause the kernel to halt. 

3. Construct the handle to data segment table in memory with as many 
rows as input num_dsegs. If there is not enough primary memory, 
cause the kernel to halt. 

4. Return NO ERROR. 





1.5 Effects 
e The amount of available memory will be reduced by the amount 
needed for configuration database, SAT, and handle table. 
e The platform may halt if insufficient memory is available. 
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1.6 Errors 
SH_C CONFIG DB LOAD ERR 
This error is returned if the data loaded from disk does not 
represent a configuration database structure. 


SH C CLUS DB LOAD ERR 
This error is returned if the data loaded from disk does not 
represent a cluster database structure. 





SH C SAT LOAD ERR 
This error is returned if the data loaded from disk does not 
represent a SAT structure. 
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22. 


sh_i_get_handle 
This function associates a specified path to a data segment with a new handle, 
which is returned to the caller. 


2.1 Prototype 
unsigned int sh_i get _handle( 
const char * const path 
const unsigned int node 
const unsigned int * handle); 


2.2 Inputs 
e path 
The absolute path in the storage hierarchy to the parent of the data 
segment to associate with a new handle. The string is null-terminated 
and cannot exceed MAX PATH LENGTH bytes in length. 
e node 
The name of the node to associate with a handle. 


2.3 Outputs 
e handle 
The handle associated with the specified path. 
e Function Result 
A numerical value that indicates success or failure of the function. 


2.4 Processing 

1. Validate that the handle table has been initialized. Cause the kernel to 
halt if the handle table has not been initialized. 

2. Validate that the specified path has not already been associated with a 
handle. Cause the kernel to halt if it has. 

3. Cause the kernel to halt if there are no handles available. 

4. Validate the input path as a correctly formed path string. Return 
SH_I MALFORMED PATH error if validation fails. 

5. Attempt to walk the storage hierarchy along the specified input path. 
Return SH_I_ PATH ERROR error if the path specified by the input 
path does not exist in the storage hierarchy. 

6. Verify that a data segment record exists for the input node and path. 
Return SH_C_NO_SUCH_NODE if it does not 

7. Verify that the specified child node is a data segment node. If it is a 
directory node, return SH_I NODE _NOT_DSEG error. 

8. Associate an entry in the handle to path database and populate it with 
the input path/node and the data segment meta-data. 

9. Set the output handle with a handle to the entry in the handle to path 
database. 

10. Return NO_ERROR 
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2.5 Effects 
e An association is made between a data segment and handle in the 
handle-to-path data database and data segment meta-data is loaded in 
memory. 
e The platform may potentially halt if this interface is called before the 
handle table has been initialized or if multiple handles are requested 
for the same data segment . 


2.6 Errors 

SH_I MALFORMED PATH 
This error is returned if the input path is not a correctly formed 
concatenated string of integer values separated by forward-slashes, 
cy % 

SH_I PATH ERROR 
This error is returned if the input path does not exist in the storage 
hierarchy tree structure. 

SH_C_NO_SUCH_ NODE 
This error is returned if the combination of input path and node 
does not exist. 

SH_I NODE NOT _DSEG 
This error is returned if the node specified by the input path is not 
designated as a data segment node. 
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sh_i_read_in 


This function supports the swap in functional requirement by copying the data 
segment from secondary storage associated with the specified handle into the 
specified buffer. 


3.1 Prototype 
unsigned int sh_i read_in( 
const unsigned int handle 
const void * buffer); 


3.2 Inputs 
e handle 
The handle associated with the desired data segment in the storage 
hierarchy. 
e buffer 


The memory buffer the data segment will be copied into. 


3.3 Outputs 
e Function Result 
A numerical value that indicates success or failure of the function. 


3.4 Processing 

1. Validate that the handle table has been initialized. Cause the kernel to 
halt if it has not been initialized. 

2. Validate the input handle is a member of the handle-to-path data 
structure. Return SH_R HANDLE _ INVALID error if it is not a 
member. 

3. Read data segment from areas of secondary storage specified by the 
meta-data associated with the handle. 

4. Copy the data associated with the specified handle into the output 
buffer. 

5. Return NO_ERROR. 


3.5 Effects 
e The contents of a segment in primary memory is modified. 
e The platform may potentially halt if this interface is called before the 
handle table has been initialized. 


3.6 Errors 
SH_R_ HANDLE INVALID 
This error is returned if the value of input handle does not exist in 
the handle-to-path data structure of the storage hierarchy. 
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4. 


sh_i_get_dseg_size 





This function returns the size of the specified data segment. 


4.1 Prototype 
unsigned int sh_r_get_dseg_size( 
const unsigned int handle 
const unsigned int * size); 


4.2 Inputs 
e handle 
The handle associated with the desired data segment in the storage 
hierarchy. 


4.3 Outputs 
e size 
The size of the specified data segment in bytes. 
e Function Result 
A numerical value that indicates success or failure of the function. 


4.4 Processing 

1. Validate that the handle table has been initialized. Cause the kernel to 
halt if it has not been initialized. 

2. Validate the input handle is a member of the handle-to-path data 
structure. Return SH_R HANDLE INVALID error if it is not a 
member. 

3. Retrieve the path associated with the handle in the handle-to-path 
database. 

4. Using the input handle to reference the handle to path table, set the 
output size with the size cached in the handle to path table. 

5. Return NO_ERROR. 


4.5 Effects 
The platform may potentially halt if this interface is called before the 
handle table has been initialized. 


4.6 Errors 
SH_R_ HANDLE INVALID 
This error is returned if the value of input handle does not exist in 
the handle-to-path data structure of the storage hierarchy. 
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5. sh_i_get_dseg_hash 





This function returns the hash value of the specified data segment. 


5.1 Prototype 
unsigned int sh_i_ get _dseg hash( 
const unsigned int handle 
const void * const buffer); 


5.2 Inputs 
e handle 
The handle associated with the desired data segment in the storage 
hierarchy. 
e buffer 
The 256-bit buffer where the hash value of the data segment will be 
placed. 
5.3 Outputs 


e Function Result 
A numerical value that indicates success or failure of the function. 


5.4 Processing 

1. Validate that the handle table has been initialized. Cause the kernel to 
halt if it has not been initialized. 

2. Validate the input handle is a member of the handle-to-path data 
structure. Return SH_R HANDLE INVALID error if it is not a 
member. 

3. Using the input handle to reference the handle to path table, set the 
output buffer with the hash value cached in the handle to table 
database. 

4. Return NO_ERROR. 


5.5 Effects 
e The platform may potentially halt if this interface is called before the 
handle table has been initialized.. 


5.6 Errors 
SH_R_ HANDLE INVALID 
This error is returned if the value of input handle does not exist in 
the handle-to-path data structure of the storage hierarchy. 
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C. RUNTIME INTERFACE 


This section describes the functions used by the LPSK during run-time. The 


functions are exposed to the LPSK as a series of function calls. They are: 
e sh_r_read in 
e sh_r write out 
e sh r get dseg size 
e sh r get dseg hash 
e sh r check hash 


The following subsections detail these functions. 
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aes 


sh_r_read_in 


This function supports the swap in functional requirement by copying the data 
segment from secondary storage associated with the specified handle into the 
specified buffer. 


1.1 Prototype 
unsigned int sh_r_read_in( 
const unsigned int handle 
const void * buffer); 


1.2 Inputs 
e handle 
The handle associated with the desired data segment in the storage 
hierarchy. 
e buffer 
The memory buffer the data segment will be copied into. 
1.3 Outputs 


e Function Result 
A numerical value that indicates success or failure of the function. 


1.4 Processing 

1. Validate that the handle table has been initialized. Cause the kernel to 
halt if it has not been initialized. 

2. Validate the input handle is a member of the handle-to-path data 
structure. Return SH_R_ HANDLE _ INVALID error if it is not a 
member. 

3. Read data segment from areas of secondary storage specified by the 
meta-data associated with the handle. 

4. Copy the data segment associated with the specified handle into the 
output buffer. 

5. Return NO_ERROR. 


1.5 Effects 
e The contents of a segment in primary memory are modified. 
e The platform may potentially halt if this interface is called before the 
handle table has been initialized. 


1.6 Errors 
SH_R_ HANDLE INVALID 
This error is returned if the value of input handle does not exist in 
the handle-to-path data structure of the storage hierarchy. 
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sh_r_write_out 


This function satisfies the functional requirements of both swap out and flush 
calls by copying the contents of the specified buffer into the data segment 
associated with the specified handle and calculating a new hash value. 


2.1 Prototype 
unsigned int sh_r_write_out( 
const unsigned int handle 
const void * const buffer); 


2.2 Inputs 
e handle 
The handle associated with the desired data segment in the storage 
hierarchy. 
e buffer 


The memory buffer the data segment will be copied from. 


2.3 Outputs 
e Function Result 
A numerical value that indicates success or failure of the function. 


2.4 Processing 

1. Validate that the handle table has been initialized. Cause the kernel to 
halt if it has not been initialized. 

2. Validate the input handle is a member of the handle-to-path data 
structure. Return SH_R HANDLE _ INVALID error if it is not a 
member. 

3. Retrieve secondary storage location information for data segment 
associated with the specified handle. 

4. Copy the contents of the specified buffer into secondary storage. 

5. Calculate and store the hash value of the contents of the data segment 
into the associated meta-data field, return NO_ ERROR. 


2.5 Effects 
e Portions of the secondary storage will be overwritten with the contents 
of the input buffer. 
e The hash value associated with the data segment is updated after new 
data has been written. 
e The platform may potentially halt if this interface is called before the 
handle table has been initialized 
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2.6 Errors 
SH_R_ HANDLE INVALID 


This error is returned if the value of input handle does not exist in 
the handle-to-path data structure of the storage hierarchy. 


117 


SEA 


sh_r_get_dseg_size 





This function returns the size of the specified data segment. 


3.1 Prototype 
unsigned int sh_r_get_dseg_size( 
const unsigned int handle 
const unsigned int * size); 


3.2 Inputs 
e handle 
The handle associated with the desired data segment in the storage 
hierarchy. 


3.3 Outputs 
e size 
The size of the specified data segment in bytes. 
e Function Result 
A numerical value that indicates success or failure of the function. 


3.4 Processing 

1. Validate that the handle table has been initialized. Cause the kernel to 
halt if it has not been initialized. 

2. Validate the input handle is a member of the handle-to-path data 
structure. Return SH_R HANDLE INVALID error if it is not a 
member. 

3. Retrieve the path associated with the handle in the handle-to-path 
database. 

4. Using the input handle to reference the handle to path table, set the 
output size with the size cached in the handle to path table. 

5. Return NO_ERROR. 


3.5 Effects 
e The platform may potentially halt if this interface is called before the 
handle table has been initialized. 


3.6 Errors 
SH_R_ HANDLE INVALID 
This error is returned if the value of input handle does not exist in 
the handle-to-path data structure of the storage hierarchy. 
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4. 


sh_r_get_dseg_hash 





This function returns the hash value of the specified data segment. 


4.1 Prototype 
unsigned int sh_r_get_dseg_hash( 
const unsigned int handle 
const void * const buffer); 


4.2 Inputs 
e handle 
The handle associated with the desired data segment in the storage 
hierarchy. 
e buffer 
The 256-bit buffer where the hash value of the data segment will be 
placed. 
4.3 Outputs 


e Function Result 
A numerical value that indicates success or failure of the function. 


4.4 Processing 

1. Validate that the handle table has been initialized. Cause the kernel to 
halt if it has not been initialized. 

2. Validate the input handle is a member of the handle-to-path data 
structure. Return SH_R HANDLE INVALID error if it is not a 
member. 

3. Using the input handle to reference the handle to path table, set the 
output buffer with the hash value cached in the handle to table 
database. 

4. Return NO_ERROR. 


4.5 Effects 
e The platform may potentially halt if this interface is called before the 
handle table has been initialized. 


4.6 Errors 
SH_R_ HANDLE INVALID 
This error is returned if the value of input handle does not exist in 
the handle-to-path data structure of the storage hierarchy. 
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sh_r_check_hash 


This function calculates the hash of the contents of the data segment associated 
with the specified handle and compares it with the hash stored in meta-data. 


5.1 Prototype 
unsigned int sh_r_check_hash( 
const unsigned int handle 
unsigned int * result); 


5.2 Inputs 
e handle 
The handle of the data segment. 


5.3 Outputs 
e result 
A value indicating the result of the hash comparison. 
e Function Result 
A numerical value that indicates success or failure of the function. 


5.4 Processing 


1. Validate that the handle table has been initialized. Cause the kernel to 
halt if it has not been initialized. 

2. Validate the input handle is a member of the handle-to-path data 
structure. Return SH_R HANDLE INVALID error if it is not a 
member. 

3. Calculate the hash of the contents of the data segment and compare the 
result with the hash stored in the meta-data associated with the data 
segment. 

4. Set the output result to HASH EQUAL if the hash calculated is the 
same as the hash stored, or HASH NOT EQUAL if the hashes are not 
equal. 

5. Return NO_ERROR. 


5.5 Effects 
e The platform may potentially halt if this interface is called before the 
handle table has been initialized. 


5.6 Errors 
SH_R_ HANDLE INVALID 
This error is returned if the value of input handle does not exist in 
the handle-to-path data structure of the storage hierarchy. 
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APPENDIX B: TEST PROCEDURES 


This appendix contains the test procedures used to produce the results located in 


Chapter IV of this work. 


A. TEST PROCEDURES 


When an interface is invoked as part of a test procedure, it is described in this 
appendix as a function call accompanied by one or more parameters. Some test 
procedures may instruct the reader to perform specific steps from a previous procedure in 
the case of large amounts of redundancy in procedures. Each test procedure indicates the 
associated test program argument(s), the values of which are found in the header files of 


the configuration and LPSK test programs. 


1 Bs Configuration Interfaces 


These test procedures are performed using the test program compiled with 
configuration interfaces and modules. Test procedures indicate which test program they 


use to perform which steps of the procedure 


sh_c_initialize_databases interface test procedure: These tests 


correspond to Test Group | as described in Table 14. 
Begin 
Configuration test program (argument value: TEST_C1) 


1. Call format function. 


2. Callsh_c_initialize databases function with block offset 
= 8, 


3. Confirm no error returned (test C1A). 
4. Call format function. 


5. Call sh_c_initialize databases function with block_offset 
= 0. 


6. Confirm error SH_C_CONFIG_DB_LOAD_ERR returned (test C1B). 














7. Call format function with cluster _database_offset = 0. 
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8. 


9. 


10. 
11. 


12. 


End 


she 


Call sh_c_initialize databases function with block_offset 
= 8. 


Confirm error SH_C_CLUS_DB_LOAD_ERR returned (test C1C). 














Call format function with SAT_offset = 0. 


Call sh_c_initialize databases function with block _offset 
= 8. 


Confirm error SH_C_SAT_LOAD_ERR returned (test C1D). 








make_dseg interface test procedure: These tests correspond to Test 


Group 2 as described in Table 15. 


Begin 


Configuration test program (argument value: TEST_C2) 


1. 
2D. 


12. 
13. 


Call format function. 


Call sh_c_initialize databases function with 
block_offset = 8. 


Call sh_c_make_dseg function with path = “/”,node = 0, and 
size = 9000. 


Confirm no error returned (test C2A.1). 


0, and 


Call sh_c_make_dseg function with path 
size = 9000. 


a alee node 





Confirm error SH_C_NODE_ALREADY_EXISTS error returned (test 
C2A.2). 


Call format function 














Call sh_c_initialize databases function with block offset 
= 8. 


Call sh_c_make_dseg function with path = “/”,node = 128, 
andsize = 9,000. 





. Confirm error __SH_C_MAX_NODE_NAME returned (test C2B). 





. Call sh_c_make_dseg function with path = “/"”,node = 0, and 


size = 134217728. 


Confirm error SH_C_DISKSPACE returned (test C2C). 








Call sh_c_make_dseg function with path = “a”,node = 0, and 
size = 9000. 
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14. 
15. 


16. 
17. 


18. 


End 


Confirm error SH_C_MALFORMED_PATH returned (test C2D). 








Call sh_c_make_dseg function with path = “/a”,node = 0, 
and size = 9000. 

Confirm error SH_C_MALFORMED_PATH returned (test C2E). 

Call sh_c_make_dseg function with path = “/0”,node = 0, 


and size = 9000. 


Confirm error SH_C_PATH_ERROR returmed (test C2F). 


sh_c_make_subtree interface test procedure: These tests correspond to Test 
Group 3 as described in Table 16. 


Begin 


Configuration test program (argument value: TEST_C3) 


1. 
2: 


12. 


13. 


Call format function. 


Call sh_c_initialize databases function with block_offset 


= 8. 


Call sh_c_make_subtree function with path = “/” and node 


Oy 


Confirm no error returned (test C3A.1). 


Call sh_c_make_subtree function with path = “/” andnode = 


Oh 





Confirm error SH_C_NODE_ALREADY_EXISTS returned (test C3A.2). 














Call sh_c_make_subtree function with path = “/” andnode = 


128. 


Confirm error _SH_C_MAX_NODE_NAME returned (test C3B). 








Call format function 


. Call sh 


= 8. 


. Call sh 


size 





Call sh 
0. 


_c_initialize databases function with block _offset 


_c_make_dseg function with path = “/”,node = 1, and 
= 134209536. 


_c_make_subtree function with path = “/” andnode = 





Confirm error SH_C_DISKSPACE returned (test C3C). 
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14. 
15. 
16. 
17. 
18. 
19. 


End 


Sh. 76: 


Call sh_c_make_subtree function with path = “a”. 


Confirm error SH_C_MALFORMED_PATH returned (test C3D). 





Call sh_c_make_subtree function with path = “/a”. 





Confirm error SH_C_MALFORMED_PATH returned (test C3E). 





Call sh_c_make_subtree function with path = “/0”. 


Confirm error SH_C_PATH_ERROR returned (test C3F). 


open_dseg interface test procedure: These tests correspond to Test 


Group 4 as described in Table 17. 


Begin 


Configuration test program (argument value: TEST_C4) 


1. 


Call format function. 
Set constant MAX_NUM_H_ROWS in configuration interfaces module to 2. 


Call sh_c_initialize databases function with block _offset 
= 8. 


Call sh_c_make_dseg function with path = “/” andnode = 
Call sh_c_make_dseg function with path = “/” andnode = 


Call sh_c_make_dseg function with path = “/” andnode = 








PWN 


Call sh_c_open_dseg function with path = “/” andnode = 
Confirm no error returned; handle zero returned (test C4A.1). 


Call sh_c_open_dseg function with path = “/” andnode = 2. 


. Confirm no error returned; handle one returned (test C4A.2). 
. Call sh_c_open_dseg function with path = “/” andnode = 3. 


. Confirm error SH_C_HANDLE_TABLE_FULL retumed (test C4A.3). 








. Call format function. 


.Call sh_c_initialize database function with block_offset 


= 8. 


. Call sh_c_open_dseg function with path = “/” andnode = 10. 





. Confirm error SH_C_NO_SUCH_NODE returned (test C4B). 





. Call sh_c_make_subtree function with path = “a”. 


. Confirm error SH_C_MALFORMED_PATH returned (test C4C). 
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19. 
20. 
21. 
2a: 


End 


Shi sG4 


Call sh_c_make_subtree function with path = “/a”. 


Confirm error SH_C_MALFORMED_PATH returned (test C4D). 





Call sh_c_make_subtree function with path = “/0”. 
Confirm error SH_C_PATH_ERROR returned (test C4E). 


write_dseg interface test procedure: These tests correspond to Test 


Group 5 as described in Table 18. 


Begin 


Configuration test program (argument value: TEST_C5) 


1. 
oa 


. Call sh_c_write_dseg function with handle = 0, buffer 


. Call sh_c_write_dseg function with handle = 1, buffer 


Call format function. 


Call sh_c_initialize databases function with block offset 
= 8. 


Call sh_c_make_dseg function with path = “/”,node = 1, and 
size = 9000. 








Call sh_c_open_dseg function with path = “/” andnode = 1; 
handle zero returned. 


Create first 9,000 byte buffer in memory and fill with 9,000 a characters; 
assign pointer buf_ptr1 to buffer. 


Generate and store hash of first buffer. 


Call sh_c_make_dseg function with path = “/”,node = 2, and 
size = 9000. 





Call sh_c_open_dseg function with path = “/” andnode = 2; 
handle one returned. 


Create second 9,000 byte buffer in memory and fill with 9,000 b 
characters; assign pointer buf_pt r2 to buffer. 


. Generate and store hash of second buffer. 


buf_ptrl,byte_count = 9000,andoffset = 0. 


. Confirm no error returned (test C5A). 


buf_ptr2,byte_count = 4500,andoffset = 0. 


. Confirm no error returned (test C5B.1). 
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15. Call sh_c_write_dseg function with handle = 1,buffer = 
buf_ptr2,byte_count = 4500,andoffset = 4500. 


16. Confirm no error returned (test C5B.2). 


17. Call sh_c_write__data function segment with handle = 2, 
buffer = buf_ptril,byte_count = 9000,andoffset = 0. 














18. Confirm error SH_C_HANDLE_INVALID returned (test C5C). 


19. Call sh_c_write_dseg function with handle = 0,buffer = 
buf_ptrl,byte_count = 9000,andoffset = 9200. 








20. Confirm error SH_C_OFFSET_BOUND_ERROR returned (test C5D). 


21. Call sh_c_write_dseg function with handle = 0,buffer = 
buf_ptrl,byte_count = 8000,andoffset = 2000. 








22. Confirm error SH_C_INSUFFICENT_SPACE returned (test C5E). 








23. Call sh_c_write_dseg function with handle = 0,buffer = 
NULL, byte_count = O,andoffset = 0. 


24. Confirm error SH_C_INPUT_BUFF_NULL returned (test CSF). 
End 





sh_c_read_dseg interface test procedure: These tests correspond to Test 
Group 6 as described in Table 19. 


Begin 
Configuration test program (argument value: TEST_C6) 
1. Repeat steps | through 16 from sh_c_write_dseg test procedure. 


2. Call sh_c_read_dseg function with handle = 0,buffer = 
buf_ptrl,byte_count = 9000,andoffset = 0. 


3. Confirm no error returned; generate new hash of first buffer and confirm it 
matches previously generated hash to determine if (test C6A). 


4. Call sh_c_read_dseg function with handle = 1,buffer = 
buf_ptr2,byte_count = 4500,andoffset = 0. 


Confirm no error returned (test C6B.1). 


6. Call sh_c_read_dseg function with handle = 1,buffer = 
buf_ptr2,byte_count = 4500,andoffset = 4500. 


7. Confirm no error returned; generate new hash of second buffer and 
confirm it matches previously generated hash (test C6B.2). 
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8. Call sh_c_read_dseg function withhandle = 2,buffer = 
buf_ptrl,byte_count = 9000,andoffset = 0. 





9. Confirm error SH_C_HANDLE_INVALID returned (test C6C). 

















10. Call sh_c_read_dseg function with handle = 0,buffer = 
buf_ptrl,byte_count = 9000,andoffset = 9200. 


11. Confirm error SH_C_OFFSET_BOUND_ERROR returned (test C6D). 





12. Call sh_c_read_dseg function with handle = 0,buffer = 
NULL, byte_count = O,andoffset = 0. 


13. Confirm error SH_C_OUTPUT_BUFF_NULL returned (test C6E). 
End 


sh_c_close_dseg interface test procedure: These tests correspond to Test 
Group 7 as described in Table 20. 


Begin 
Configuration test program (argument value: TEST_C7) 
1. Repeat steps | through 6 from sh_c_write_dseg test procedure. 
2. Call sh_c_close_dseg function with handle = 0. 
3. Confirm no error returned. 
4 


Call sh_c_get_dseg_hash function with path = “/” and node 
= 1; compare returned hash with previous generated hash (test C7A.1). 





Call sh_c_close_dseg function with handle = 1. 





Confirm error SH_C_HANDLE_INVALID returned (test C7A.2). 




















Confirm error SH_C_HANDLE_INVALID returned (test C7B). 

















5 
6 
7. Call sh_c_close_dseg function with handle = 2. 
8 
d 


sh_c_delete_dseg interface test procedure: These tests correspond to Test 
Group 8 as described in Table 21. 


Begin 
Configuration test program (argument value: TEST_C8) 
1. Call format function. 


2. Callsh_c_initialize databases function with block offset 
= 8. 
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3. Call sh_c_make_dseg function with path = “/”,node = 1, and 
size = 9000. 


4. Call sh_c_make_subtree function with path = “/” andnode = 
2. 





5. Call sh_c_delete_dseg function with path = “/” andnode = 
th 


6. Confirm no error returned (test C8A.1). 


7. Call sh_c_delete_dseg function with path = “/” and node 
1. 


8. Confirm error SH_C_NO_SUCH_NODE returned (test C8A.2). 








9. Call sh_c_delete_dseg function with path = “/” and node 
128. 


10. Confirm error SH_C_MAX_NODE_NAME returned (test C8B). 








11. Call sh_c_delete_dseg function with path = “/” andnode = 
O. 


12. Confirm error SH_C_NO_SUCH_NODE returned (test C8C). 








13. Call sh_c_delete_dseg function with path = “/” andnode = 
2. 


14. Confirm error SH_C_NODE_NOT_DSEG returned (test C8D). 











15. Call sh_c_delete_dseg function with path = “a”. 
16. Confirm error SH_C_MALFORMED_PATH returned (test C8E). 


17. Call sh_c_delete_dseg function with path = “/a”. 





18. Confirm error SH_C_MALFORMED_PATH returned (test C8F). 
19. Call sh_c_delete_dseg function with path = “/0”. 
20. Confirm error SH_C_PATH_ERROR returned (test C8G). 

End 


sh_c_delete_subt ree interface test procedure: These tests correspond to 
Test Group 9 as described in Table 22. 


Begin 
Configuration test program (argument value: TEST_C9) 


1. Call format function. 


128 


Call sh_c_initialize databases function with block_offset 






































= 8, 

Call sh_c_make_subtree function with path = “/” and node 
1 

Call sh_c_make_subtree function with path = “/1” and node 
= 1. 

Call sh_c_make_subtree function with path = “/1” and node 
= 2. 

Call sh_c_make_dseg function with path = “/1/1” and node 
Call sh_c_make_dseg function with path = “/1/2” and node 








Call sh_c_delete_subtree function with path = “/1/1” and 


node = 1. 











Confirm error SH_C_NODE_DIRNODE returned (test C9A). 





= 1. 


. Confirm no error returned (test C9B.1). 
. Call sh_c_ delete subtree with path = “/” andnode = 1. 
. Confirm error SH_C_NO_SUCH_NODE returned (test C9B.2). 








. Call sh_c_ delete subtree with path = “/1” andnode = 1. 
. Confirm error SH_C_PATH_ERROR returned (test C9B.3). 
. Call sh_c_ delete subtree with path = “/” andnode = 128. 





. Confirm error SH_C_MAX_NODE_NAME returned (test C9C). 





. Call sh_c_ delete subtree with path = “/” andnode = 0. 
. Confirm error SH_C_NO_SUCH_NODE returned (test C9D). 








. Call sh_c_delete_subtree function with path = “a”. 





. Confirm error SH_C_MALFORMED_PATH returned (test C9E). 
. Call sh_c_delete_subtree function with path = “/a”. 
. Confirm error SH_C_MALFORMED_PATH returned (test C9F). 





. Call sh_c_delete_subtree function with path = “/0”. 


. Confirm error SH_C_PATH_ERROR returned (test C9G). 
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. Call sh_c_delete_subtree function with path = “/” and node 


End 


she 


get_child interface test procedure: These tests correspond to Test 


Group 10 as described in Table 23. 


Begin 


Configuration test program (argument value: TEST_C10) 


di. 
2: 


Repeat steps 1 through 7 from sh_c_delete_subt ree test procedure. 


Call sh_c_get_child function with path = “/”,node = 1, and 
offset = 0. 


Confirm no error returned; expected node name 1 and directory node type 
returned (test C10A). 


Call sh_c_get_child function with path = “/”,node = 1, and 
offset = l. 


Confirm no error returned; expected node name 2 and directory node type 
returned (test C10B). 


Call sh_c_get_child function with path = “/”,node = 1, and 
offset = 2. 


Confirm error SH_C_OFFSET_BOUND_ERROR returned (test C10C). 





Call sh_c_get_child function with path = “/1”,node = 1, 
andoffset = 0. 


Confirm no error returned; expected node name | and data segment node 
type returned (C10D). 


. Call sh_c_get_child function with path = “/1/1",node = 1, 


andoffset = 0. 








. Confirm error SH_C_NODE_NOT_DSEG returned (test C10E). 





. Call sh_c_get_child function with path = “/",node = 128, 


andoffset = 0. 





. Confirm error SH_C_MAX_NODE_NAME returned (test C10F). 





. Call sh_c_get_child function with path = “/”,node = 0, and 


offset = 0. 


. Confirm error SH_C_NO_SUCH_NODE returned (test C10G). 








. Call sh_c_delete_subtree function with path = “a”. 


. Confirm error SH_C_MALFORMED_PATH returned (test C10H). 





. Call sh_c_delete_subtree function with path = “/a”. 
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19. Confirm error SH_C_MALFORMED_PATH returned (test C10I). 





20. Call sh_c_delete_subtree function with path = “/0”. 
21. Confirm error SH_C_PATH_ERROR returned (test C10J). 
End 


sh_c_get_dseg_size interface procedure test: These tests correspond to 
Test Group 11 as described in Table 24. 


Begin 
Configuration test program (argument value: TEST_C11) 





1. Call format function 
2. Callsh_c_initialize databases function with block offset 
= 8. 


3. Call sh_c_make_dseg function with path = “/”,node = 1, and 


size = 9000. 


4. Call sh_c_make_subtree function with path = “/” andnode = 
2. 








5. Call sh_c_get_dseg_size function with path = “/” andnode 
= 1. 





6. Confirm no error returned; 9,000 bytes returned (test C1 1A). 


7. Call sh_c_get_dseg_size function with path = “/” andnode 
= 2. 





8. Confirm error SH_C_NODE_NOT_DSEG returned (test C11B). 











9. Call sh_c_get_dseg_size function with path = “/” andnode 
= 3. 





10. Confirm error SH_C_NO_SUCH_NODE returned (test C11C). 








11. Call sh_c_get_dseg_size function with path = “/” and node 
= 128. 





12. Confirm error SH_C_MAX_NODE_NAME returned (test C11D). 








13. Call sh_c_get_dseg_size function with path = “a”. 








14. Confirm error SH_C_MALFORMED_PATH returned (test C11E). 


15. Call sh_c_get_dseg_size function with path = “/a”. 





16. Confirm error SH_C_MALFORMED_PATH returned (test C11F). 





17. Call sh_c_get_dseg_size function with path = “/0”. 
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18. Confirm error SH_C_PATH_ERROR returmed (test C11G). 
End 


sh_c_get_dseg_hash interface procedure test: These tests correspond to 
Test Group 12 as described in Table 25. 


Begin 
Configuration test program (argument value: TEST_C12) 





1. Repeat steps | through 4 from sh_c_get_dseg_size test procedure. 





2. Call sh_c_open_dseg function with path = “/” andnode = 1; 
handle zero returned. 


3. Create 9,000 byte buffer in memory and fill with 9,000 a characters; 
assign pointer buf_ptr1 to buffer. 


4. Generate and store hash of buffer. 


5. Call sh_c_write_dseg function withhandle = 0,buffer = 
buf_ptrl,byte_count = 9000,andoffset = 0. 





6. Call sh_c_close_dseg function with handle = 0. 


7. Call sh_c_make_subtree function with path = “/” andnode = 











2 
8. Call sh_c_get_dseg_hash function with path = “/” and node 
= 1. 
9. Confirm no error returned; compare returned hash with previous generated 
hash (test C12A). 
10. Call sh_c_get_dseg_hash function with path = “/” and node 
= 2. 


11. Confirm error SH_C_NODE_NOT_DSEG returned (test C12B). 











12. Call sh_c_get_dseg_hash function with path = “/” and node 
= 3. 





13. Confirm error SH_C_NO_SUCH_NODE returned (test C12C). 








14. Call sh_c_get_dseg_hash function with path = “/” and node 
= 128. 





15. Confirm error SH_C_MAX_NODE_NAME returned (test C12D). 





16. Call sh_c_get_dseg_hash function with path = “a”. 








17. Confirm error SH_C_MALFORMED_PATH returned (test C12E). 





18. Call sh_c_get_dseg_hash function with path = “/a”. 
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19. Confirm error SH_C_MALFORMED_PATH returned (test C12F). 





20. Call sh_c_get_dseg_hash function with path = “/0”. 





21. Confirm error SH_C_PATH_ERROR returmed (test C12G). 
End 


sh_c_check_hash interface test procedure: These tests correspond to Test 
Group 13 as described in Table 26. 


Begin 
Configuration test program (argument value: TEST_C13) 


1. Repeat steps | through 7 from sh_c_get_dseg_hash test procedure. 





2. Call sh_c_check_hash function with path = “/”,andnode = 
the 


Confirm no error returned; confirm true value returned (test C13.A) 
Call sh_c_check_hash function with path = “/” andnode = 2. 


Confirm error SH_C_NODE_NOT_DSEG returned (test C13B). 











Call sh_c_check_hash function with path = “/” andnode = 3. 





Confirm error SH_C_NO_SUCH_NODE returned (test C13C). 





aT oy. ee 2 


Call sh_c_check_hash function with path = “/” andnode = 
128. 


9. Confirm error SH_C_MAX_NODE_NAME returned (test C13D). 








10. Call sh_c_check_hash function with path = “a”. 
11. Confirm error SH_C_MALFORMED_PATH returned (test C13E). 





12. Call sh_c_check_hash function with path = “/a”. 
13. Confirm error SH_C_MALFORMED_PATH returned (test C13F). 








14. Call sh_c_check_hash function with path = “/0”. 
15. Confirm error SH_C_PATH_ERROR returmed (test C13G). 
End 
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2: Initialization Interfaces 


Initialization interface test procedures require use of both configuration and LPSK 
test tools described in Chapter IV. Test procedures indicate which test program they use 


to perform which steps of the procedure. 


sh_i_initialize_databases interface test procedures: These tests 


correspond to Test Group | as described in Table 27. 


Begin 





Configuration test program (argument value: TEST_I1A): 


1. Call format function. 





LPSK test program (argument value: TEST_I1A): 


2. Callsh_i initialize databases function with block offset 
= 8. 


Confirm no error returned (test I] A). 
4. Restart LPSK test program: 


5. Callsh_i_ initialize databases function with block _offset 
= Oandnum_dsegs = 1. 





6. Confirm error SH_C_CONFIG_DB_LOAD_ERR returned (test I1B). 














Configuration test program (argument value: TEST_I1B): 


7. Call format function with cluster database offset = 0. 





LPSK test program (argument value: TEST_I1B): 


8. Call sh_i_initialize databases function with block offset 
= 8andnum_dsegs = 1. 


9. Confirm error SH_C_CLUS_DB_LOAD_ERR returmed (test I1C). 

















Configuration test program (argument value: TEST_I1B): 


10. Call format function with SAT_offset = 0. 








LPSK test program (argument value: TEST_I1B): 





11. Call sh_i_ initialize databases function with 
block_offset = 8 andnum_dsegs = 1. 





12. Confirm error SH_C_SAT_LOAD_ERR returned (test I1D). 
End 








134 


sh_i_ 


get_handle interface test procedure: These tests correspond to Test 


Group 2 as described in Table 28. 


Begin 





Configuration test program (argument value: TEST_I2): 


1. 
oe 


Call format function. 


Call sh_c_sh_c_initialize databases function with 
block_offset = 8. 


Call sh_c_sh_c_make_dseg function with path = “/” and node 
= 1. 








Call sh_c_sh_c_make_dseg function with path = “/” and node 
= 2. 

















Call sh_c_sh_c_make_subtree function with path = “/” and 
node = 3. 








LPSK test program (argument value: TEST_I2): 


6. 


. Call sh_i_get_handle function with path = “/” andnode = 


Call sh_i_ initialize databases function with block _offset 
= 8andnum_dsegs = 1. 


Call sh_i_get_hand1le function with path = “/” andnode = 1. 


Confirm no error returned; handle zero returned (test I2A.1). 


ll 
Nh 


Call sh_i_get_hand1le function with path = “/” and node 


. Confirm error SH_C_HANDLE_TABLE_FULL returned (test I2A.2). 








.Call sh_i_ initialize databases function with block offset 


= 8andnum_dsegs = 1. 


. Call sh_i_get_hand1le function with path = “/” andnode = 3. 





. Confirm error SH_C_NODE_NOT_DSEG returned (test I2B) 








. Call sh_i_get_handle function with path = “/” andnode = 


10. 








. Confirm error SH_C_NO_SUCH_NODE returned (test I2C). 


128. 


. Confirm error SH_C_MAX_NODE_NAME returned (test I2D). 











. Confirm error SH_C_MALFORMED_PATH returned (test I2E). 
. Call sh_i_check_hash function with path = “/a”. 








. Confirm error SH_C_MALFORMED_PATH returned (test I2F). 
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ali 
22: 


End 


sh_i_ 


Call sh_i_check_hash function with path = “/0”. 
Confirm error SH_C_PATH_ERROR returned (test I2G). 


read_in interface test procedure: These tests correspond to Test Group 


3 as described in Table 29. 


Begin 





Configuration test program (argument value: TEST_I3): 


1. 
De 


6. 


Call format function. 


Call sh_c_initialize databases function with block offset 
= 8. 


Call sh_c_make_dseg function with path = “/” andnode = 1. 


Create 9,000 byte buffer in memory and fill with 9,000 a characters; 
assign pointer buf_ptr1 to buffer. 


Call sh_c_write_dseg function with handle = 0,buffer = 
buf_ptrl,byte_count = 9000,andoffset = 0. 





Call sh_c_close_dseg function with handle = 0. 





LPSK test program (argument value: TEST_1I3): 


ve 


sh_i 


Call sh_i_ initialize databases function with block _offset 
= 8andnum_dsegs = 1. 


Call sh_i_get_hand1le function with path = “/” andnode = 1. 


Create 9,000 byte buffer in memory; assign pointer buf_ptr1 to buffer. 


.Call sh_i_read_in function with handle = Oandbuffer = 


buf_ptrl. 


. Confirm no error returned; confirm contents of buffer matches data written 


to the data segment created in step 4 (test I3A). 


.Call sh_i_read_in function with handle = landbuffer = 


buf_ptrl. 





. Confirm error SH_C_HANDLE_INVALID returned (test I3B). 




















get_dseg_size interface test procedure: These tests correspond to 


Test Group 4 as described in Table 30. 


Begin 
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Configuration test program (argument value: TEST_I 


1. Call format function. 


4): 


2. Callsh_c_initialize databases function with block offset 


8. 
3. Call sh_c_make_dseg function with path 


[ 4): 





LPSK test program (argument value: TEST_1 
4. 


8 and num_dsegs dy, 














Confirm error SH_C_HANDLE __ 








NVAL 











BCMA DY 


Call sh_i_get_hand_1e function with path 
Call sh_i_get_dseg_size function with handle 


Call sh_i_get_dseg_size function with handle 


= “/"” and node 12 


Call sh_i_ initialize databases function with block _offset 


“/"” and node 


0. 


dhs 


Confirm no error returned; confirm 9,000 size output returned (test I4A). 


ilk. 


D returned (test I4B). 


sh_i_get_dseg_hash interface test procedure: These tests correspond to 





Test Group 5 as described in Table 31. 


Begin 
Configuration test program (argument value: TEST_1 











[5): 





1. Call sh_c_format function. 

2. Call sh_c_initialize databases function with block_offset 
= 8, 

3. Call sh_c_make_dseg function with path = “/” andnode = 

4. Call sh_c_open_dseg function with path = “/” andnode = 1; 
handle zero returned. 

5. Create 9,000 byte buffer in memory and fill with 9,000 a character; assign 
pointer buf_ptr1 to buffer. 

6. Generate and store hash of buffer. 

7. Call sh_c_write_dseg function withhandle = 0,buffer = 
buf_ptrl,byte_count = 9000,andoffset = 0. 

8. Call sh_c_close_dseg function with handle = 0. 





LPSK test program (argument value: TEST_I5): 
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9. 


Call sh_i_ initialize databases function with block _offset 
= 8andnum_dsegs = 1. 


10. Call sh_i_get_handle function with path = “/” andnode = 1. 





11. Call sh_i_get_dseg_hash function with handle = 0. 





12. Confirm no error returned; confirm returned hash matches previously 


generated hash (test ISA). 


13. Call sh_i_get_dseg_hash function with handle = 1. 











14. Confirm error SH_C_HANDLE_INVALID returned (test ISB). 


End 


3. 














Runtime Interfaces 


Runtime interface test procedures require use of both configuration and LPSK test 


tools described in Chapter IV. Test procedures indicate which test program they use to 


perform which steps of the procedure Some tests procedures are performed immediately 


after previous test procedures with no break in program execution. Instructions to 


continue to the next test procedure are appended to these test procedures. 


sh_r_read_in interface test procedure: These tests correspond to Test Group 
1 as described in Table 32. 


Begin 


Configuration test program (argument value: TEST_R1): 


1. 
pis 


6. 


Call sh_c_ format function. 


Call sh_c_initialize_databases function with block_offset 
= 8. 

Call sh_c_make_dseg function with path = “/”,node = 1, and 
size = 9,000. 

Create 9,000 byte buffer in memory and fill with 9,000 a characters; 
assign pointer buf_ptr1 to buffer. 


Call sh_c_write_dseg function with handle = 0,buffer = 
buf_ptrl,byte_count = 9000,andoffset = 0. 





Call sh_c_close_dseg function with handle = 0. 


LPSK test program (argument value: TEST_R1): 
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13. 


Call sh_i_ initialize databases function with block _offset 
= 8andnum_dsegs = 1. 


Call sh_i_get_hand1le function with path = “/” andnode = 1. 


Create 9,000 byte buffer in memory; assign pointer buf_ptr1 to buffer. 


.Call sh_r_read_in function with handle = Oandbuffer = 


but ptr. 


. Confirm no error returned; confirm contents of buffer matches data written 


to the data segment created in step 4 (test RIA). 


.Call sh_r_read_in function with handle = landbuffer = 


buf_ptrl. 





Confirm error SH_C_HANDLE_INVALID returned (test R1B). 

















Continue to next test procedure 


sh_r_write_out interface test procedure: These tests correspond to Test 
Group 2 as described in Table 33. 


Begin 


LPSK test program (argument value: TEST_R2): 


1. 


OY OY oR ORS 


Ts 


Generate and store the hash of buffer created and written to in steps 9 and 
10 of the sh_r_read_in test procedure. 


Overwrite the contents of the buffer with new data. 


Generate and store the hash of the buffer. 


Call write out function with handle = Oandbuffer = buf_ptrl. 
Confirm no error return returned (test R2A). 


Call write out function with handle = Oandbuffer = buf_ptrl. 





Confirm error SH_C_HANDLE_INVALID returned (test R2B). 

















Continue to next test procedure 


sh_r 


get_dseg_hash interface test procedure: These tests correspond to 





Test Group 3 as described in Table 34. 


Begin 


LPSK test program (argument value: TEST_R3): 


1. 


Call sh_r_get_dseg_hash function with handle = 0. 
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2. Confirm no error returned; compare hash value compared to hash 
generated in step 3 of the sh_r_write_out test procedure (test R3A). 


3. Call sh_r_get_dseg_hash function with handle = 1. 











4. Confirm error SH_C_HANDLE_INVALID returned (test R3B). 
End 


sh_r_get_dseg_size interface test procedure: These tests correspond to 
Test Group 4 as described in Table 35. 


Begin 
Configuration test program (argument value: TEST_R4): 

















1. Call sh_c_format function. 


2. Callsh_c_initialize databases function with block offset 
= 8. 


3. Call sh_c_make_dseg function with path = “/"”,node = 1, and 
size = 9,000. 


LPSK test program (argument value: TEST_R4): 


4. Call sh_i_initialize databases function with block_offset 
= 8andnum_dsegs = 1. 


Call sh_i_get_hand_1le function with path = “/” andnode = 1. 





Call sh_r_get_dseg_size function with handle = 0. 





Confirm no error returned; 9,000 size output returned (test R4A). 
Call sh_r_get_dseg_size function with handle = 1. 
Confirm error SH_C_ HANDLE INVALID returned (test R4A). 





BoC wm ND 


sh_r_check_hash interface test procedure: These tests correspond to Test 
Group 5 as described in Table 36. 


Begin 
Configuration test program (argument value: TEST_R5): 
1. Call sh_c_format function. 


2. Callsh_c_initialize databases function with block offset 
= 8. 


3. Call sh_c_make_dseg function with path = “/”,node = 1, and 
size = 9,000. 
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4. Call sh_c_open_dseg function with path = “/” andnode = 1; 
handle zero returned. 


5. Create 9,000 byte buffer in memory and fill with 9,000 a characters; 
assign pointer buf_ptr1 to buffer. 


6. Generate and store hash of buffer. 


7. Call sh_c_write_dseg function withhandle = 0,buffer = 
buf_ptrl,byte_count = 9000,andoffset = 0. 





8. Call sh_c_close_dseg function with handle = 0. 
LPSK test program (argument value: TEST_R6): 


10. Call sh_i_ initialize databases function with block_offset 
= 8andnum_dsegs = 1. 


11. Call sh_i_get_handle function with path = “/” andnode = 1. 
12. Call sh_r_check_hash function with handle = 0. 
13. Confirm no error returned; confirm true value returned (test R5A). 
14. Call sh_r_check_hash_function with handle = 1. 
15. Confirm error SH_C_NODE_NOT_DSEG returned (test R5B). 
End 
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